> If script startup and module loading really is the culprit you could try the
> mod_perl approach.
>
> Load all required modules and then for each script, fork a new perl process
> which uses do "testxxx.t" to run each script.
That's a good idea - thanks!
I gave it a try and these are the times
On Tue, Mar 08, 2005 at 10:11:09PM -0500, Michael Graham wrote:
>
> > > Would this make it possible to run many test scripts (each with its own
> > > plan) within the same perl process? 'Cos that would be nifty.
> >
> > Yes. Though beyond testing testing libraries I don't know why you'd want to
On Tue, Mar 08, 2005 at 10:11:09PM -0500, Michael Graham wrote:
> Well, all I was going to do was try to shave a few seconds off the
> running time of my test suite (which is now climbing up to the 10 minute
> mark). I figured I could do the mod_perl thing: preload all my modules
> and do most of
On Tue, Mar 08, 2005 at 10:30:36PM -0500, Randy W. Sims wrote:
> What about the "resource aquisition is initialization" approach?
Oh ick no. Means on every subroutine entry you have to call a magic,
mysterious TB method.
> package TB;
> sub new { bless { level => \my $level }, shift }
> sub obt
Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 10:31:48PM +, Fergal Daly wrote:
No, other way around. When a TB instance needs a TB::Counter it just says
$tb->counter which, normally, returns a singleton but you can alter counter()
so it returns something else.
A singleton is a class that o
> > Would this make it possible to run many test scripts (each with its own
> > plan) within the same perl process? 'Cos that would be nifty.
>
> Yes. Though beyond testing testing libraries I don't know why you'd want to
> do that.
Well, all I was going to do was try to shave a few seconds off
I was playfully suggesting that behind simply as an abstraction of what
Test::Builder and Test::Harness provide. No way would I inflict that on
an end-user!
David
Ofer Nave wrote:
David Golden wrote:
Just to be playful with concepts:
* Test::Answer -- holds the details of a particular test
(pa
David Golden wrote:
Just to be playful with concepts:
* Test::Answer -- holds the details of a particular test
(pass/fail/skip/todo)
* Test::Scoresheet -- holds a collection of Test::Answers
* Test::Booklet -- sets up a default Test::ScoreSheet object to hold
results, creates and maintains new o
chromatic wrote:
On the other hand, it doesn't do anything differently with TAP as
currently defined, and I share Schwern's case of howling fantods at
recommending that people look in Test::Builder's test results list. Out
of process interpreting and reporting feels so much nicer.
An addendum o
On Tue, Mar 08, 2005 at 03:05:16PM -0800, Michael G Schwern wrote:
> > A singleton is a class that only ever has 1 instance in existence. If there
> > can be multiple instances of TB::Counter or TB::Run then by definition
> > neither of them are singletons. Conversely if there is only ever 1 instan
chromatic wrote:
On Tue, 2005-03-08 at 17:31 -0500, David Golden wrote:
Yeah, it would be nice if we had a better way to handle this. Perhaps
changing the idiom to:
$Test->ok( $dressed_up, 'How nice do you look?' ) ||
$Test->reason( 'Refusing to wear a tie and jacket' );
and enc
On Tue, 2005-03-08 at 17:31 -0500, David Golden wrote:
> Let me say it a different way. Right now, Test::Builder and
> Test::Harness (et al.) are tightly coupled. It would be nice to break
> or at least reduce that coupling. Stuff deep in Test::Builder assumes
> that the output is TAP. For
On Tue, Mar 08, 2005 at 05:31:27PM -0500, David Golden wrote:
> It would be nice if there were better symmetry so that something
> like is() could stick its "got X, expected Y" message in "reason" field
> of the details array if it fails.
That's a good idea.
On Tue, Mar 08, 2005 at 10:31:48PM +, Fergal Daly wrote:
> > No, other way around. When a TB instance needs a TB::Counter it just says
> > $tb->counter which, normally, returns a singleton but you can alter
> > counter()
> > so it returns something else.
>
> A singleton is a class that only
On Tue, Mar 08, 2005 at 05:35:28PM -0500, David Golden wrote:
> >This is too simplistic for Various Reasons that chromatic and I are still
> >hashing out.
>
> Care to hash in public?
What do you think this thread is about?
On Tue, Mar 08, 2005 at 05:05:02PM -0500, David Golden wrote:
> doing the what I want before I write it. I think the approach works,
> but all this mucking about in the internals of Test::Builder feels like
> voodoo.
All the vodoo has already been done for Test::Tester.
my @results = run_tests
Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 02:54:46PM -0500, David Golden wrote:
Could we also consider moving away from singletons that are hard-wired
to Test::Builder? By that I mean make Test::Builder a 'factory' that
gives either a default, plain vanilla Test::Builder object or else
On Tue, Mar 08, 2005 at 01:42:49PM -0800, Michael G Schwern wrote:
> On Tue, Mar 08, 2005 at 09:36:24PM +, Fergal Daly wrote:
> > Cool, so actually T::B::Counter and T::B::Run are not singletons and
> > Test::Builder is.
>
> No, other way around. When a TB instance needs a TB::Counter it just
chromatic wrote:
On Tue, 2005-03-08 at 14:54 -0500, David Golden wrote:
Also, in thinking through the reorg of Test::Builder, it would be great
if the notion of "success" or "failure" could be isolated from any
particular form of output. That would mean that someone could use
Test::Builder::
On Tue, Mar 08, 2005 at 05:05:02PM -0500, David Golden wrote:
> The use case I've been pondering is to be able to better control the
> granularity of my tests within a particular scripts. Stuff like
> Test::Class and Test::Block gets closer but not quite to what I would
> like. I'd like to be
On Tue, Mar 08, 2005 at 01:44:13PM -0800, Ofer Nave wrote:
> How is CPAN going to support simultaneous development of perl 5 and 6
> versions of modules?
Last I heard Perl 6 will have a completely separate directory from the Perl 5
stuff allowing them to shed any legacy even at the CPAN layout le
Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 03:39:17PM -0500, Michael Graham wrote:
Something that's been sitting in the Test::Builder repository for a while
now is Test::Builder->create. Finally you can create a second Test::Builder
instance. I haven't done much with i
On Tue, Mar 08, 2005 at 02:39:53PM -0600, Andy Lester wrote:
> On Tue, Mar 08, 2005 at 12:36:30PM -0800, Michael G Schwern ([EMAIL
> PROTECTED]) wrote:
> > Sorry to contradict, but yes it does. All the test methods return if they
> > passed or failed. That's how the "ok( open FILE, "foo" ) || di
chromatic wrote:
I've been writing notes for Test::Builder for Perl 6, though. It's a
little something like:
How is CPAN going to support simultaneous development of perl 5 and 6
versions of modules?
-ofer
On Tue, Mar 08, 2005 at 03:39:17PM -0500, Michael Graham wrote:
> > Something that's been sitting in the Test::Builder repository for a while
> > now is Test::Builder->create. Finally you can create a second Test::Builder
> > instance. I haven't done much with
On Tue, Mar 08, 2005 at 09:36:24PM +, Fergal Daly wrote:
> Cool, so actually T::B::Counter and T::B::Run are not singletons and
> Test::Builder is.
No, other way around. When a TB instance needs a TB::Counter it just says
$tb->counter which, normally, returns a singleton but you can alter co
On Tue, Mar 08, 2005 at 12:50:29PM -0800, chromatic wrote:
> On Tue, 2005-03-08 at 20:40 +, Fergal Daly wrote:
>
> > By singleton do you mean that there's only ever 1 Test::Builder::Counter and
> > it's shared between all the Test::Builder objects?
>
> By default there's only one. You can cr
On Tue, 2005-03-08 at 20:40 +, Fergal Daly wrote:
> By singleton do you mean that there's only ever 1 Test::Builder::Counter and
> it's shared between all the Test::Builder objects?
By default there's only one. You can create others, if necessary.
> One way to allow this is to have a single
On Tue, Mar 08, 2005 at 12:36:30PM -0800, Michael G Schwern ([EMAIL PROTECTED])
wrote:
> Sorry to contradict, but yes it does. All the test methods return if they
> passed or failed. That's how the "ok( open FILE, "foo" ) || diag $!"
> idiom works.
Right, but not on the larger scale. The "okne
By singleton do you mean that there's only ever 1 Test::Builder::Counter and
it's shared between all the Test::Builder objects? That's necessary in order
to maintain consitent numbering of tests but it doesn't allow for a
second counter to be established to temporarily count subtests (for example
w
> Something that's been sitting in the Test::Builder repository for a while
> now is Test::Builder->create. Finally you can create a second Test::Builder
> instance. I haven't done much with it and I think $Level is still global
> across all instances (bug) but I fi
On Tue, Mar 08, 2005 at 02:29:22PM -0600, Andy Lester wrote:
> On Tue, Mar 08, 2005 at 12:21:35PM -0800, Michael G Schwern ([EMAIL
> PROTECTED]) wrote:
> > > Also, in thinking through the reorg of Test::Builder, it would be great
> > > if the notion of "success" or "failure" could be isolated fro
On Tue, Mar 08, 2005 at 12:21:35PM -0800, Michael G Schwern ([EMAIL PROTECTED])
wrote:
> > Also, in thinking through the reorg of Test::Builder, it would be great
> > if the notion of "success" or "failure" could be isolated from any
> > particular form of output. That would mean that someone c
On Tue, Mar 08, 2005 at 02:54:46PM -0500, David Golden wrote:
> Could we also consider moving away from singletons that are hard-wired
> to Test::Builder? By that I mean make Test::Builder a 'factory' that
> gives either a default, plain vanilla Test::Builder object or else a
> specific subclass
On Tue, Mar 08, 2005 at 12:09:02PM -0800, chromatic wrote:
> > > Test::Builder::TestResults - the parent class for all types of tests
> > > (pass, fail, todo, skip). This may be too much detail here, but I like
> > > the idea of these knowing how to format themselves for output.
> >
> > Dunno wha
On Tue, 2005-03-08 at 11:40 -0800, Michael G Schwern wrote:
> > Test::Builder::TestResults - the parent class for all types of tests
> > (pass, fail, todo, skip). This may be too much detail here, but I like
> > the idea of these knowing how to format themselves for output.
>
> Dunno what this i
On Tue, 2005-03-08 at 14:54 -0500, David Golden wrote:
> Could we also consider moving away from singletons that are hard-wired
> to Test::Builder? By that I mean make Test::Builder a 'factory' that
> gives either a default, plain vanilla Test::Builder object or else a
> specific subclass? E.g
Having an instance is great.
Could we also consider moving away from singletons that are hard-wired
to Test::Builder? By that I mean make Test::Builder a 'factory' that
gives either a default, plain vanilla Test::Builder object or else a
specific subclass? E.g.,
use Test::Builder 'Test::Build
On Tue, Mar 08, 2005 at 11:24:59AM -0800, chromatic wrote:
> > chromatic, do you still have those notes?
>
> Hm, not anywhere close. I think they were on your laptop, the one you
> took apart at the last TPC in San Diego.
Then it may be gone as Apple ate my last hard drive. It possible I have
a
On Tue, 2005-03-08 at 10:25 -0800, Michael G Schwern wrote:
> What's still missing is a way to swap out the Test::Builder singleton with
> your own custom subclass instance. There's some complicated issues there
> which chromatic and I talked over a couple years ago and then promptly did
> nothin
Something that's been sitting in the Test::Builder repository for a while
now is Test::Builder->create. Finally you can create a second Test::Builder
instance. I haven't done much with it and I think $Level is still global
across all instances (bug) but I figured folks would want to
41 matches
Mail list logo
