On Nov 8, 2012, at 7:17 AM, Mark Stosberg wrote:
>> I wasn't able to get forkprove to work with Test::Class, because of
> Test::Class's insistence that tests be declared at compile time.
>>
>> swartz> cat t/Sanity.t
>> #!/usr/bin/perl
>> use CHI::t::Sanity;
>> CHI::t::Sanity->runtes
> I wasn't able to get forkprove to work with Test::Class, because of
Test::Class's insistence that tests be declared at compile time.
>
>swartz> cat t/Sanity.t
>#!/usr/bin/perl
>use CHI::t::Sanity;
>CHI::t::Sanity->runtests;
>
>swartz> forkprove t/Sanity.t
>t/Sanity.t
> On 11/07/2012 03:51 PM, Jonathan Swartz wrote:
>> Now on cpan. A much simpler solution than what I suggested :) and apparently
>> still works with parallel testing. Thanks miyagawa!
>>
>> https://metacpan.org/module/forkprove
>
> I did some benchmarking last night and found no real benefit
On 11/07/2012 03:51 PM, Jonathan Swartz wrote:
> Now on cpan. A much simpler solution than what I suggested :) and apparently
> still works with parallel testing. Thanks miyagawa!
>
>https://metacpan.org/module/forkprove
I did some benchmarking last night and found no real benefit over prove
ould speed things up if we could share that loading
>> cost.
>>
>> I'm aware of Test::Aggregate and Test::Aggregate::Nested, but a number of
>> our tests run into the caveats (e.g. they change singletons -- yes, this is
>> not ideal, but also not easily changeable).
On 11/06/2012 01:25 PM, Karen Etheridge wrote:
> On Tue, Nov 06, 2012 at 09:59:48AM -0800, Jonathan Swartz wrote:
>> For each test run, instead of loading a .t file, you're making a request
>> against the Starman server. So you can obviously hit it with multiple
>> simultaneous requests.
>
> For
On Tue, Nov 06, 2012 at 09:59:48AM -0800, Jonathan Swartz wrote:
> For each test run, instead of loading a .t file, you're making a request
> against the Starman server. So you can obviously hit it with multiple
> simultaneous requests.
For something so simple, you could also use Parallel::ForkM
other book - http://www.oreilly.com/catalog/perlhks/
> Live and work overseas - http://www.overseas-exile.com/
> From: Jonathan Swartz
> To: perl-qa
> Sent: Tuesday, 6 November 2012, 2:03
> Subject: preforking prove
>
> We have a large slow test suite at work (Test::Cla
On Nov 6, 2012, at 12:08 AM, Eric Wilhelm wrote:
> Hi Jonathan,
>
> I like the idea. I rambled along similar lines a few years ago but
> don't think I got past some preliminary code and $work has not had any
> pressing need for such a thing in the meantime.
>
>> * works well with parallel pr
oading
> cost.
>
> I'm aware of Test::Aggregate and Test::Aggregate::Nested, but a number of our
> tests run into the caveats (e.g. they change singletons -- yes, this is not
> ideal, but also not easily changeable).
>
> I thought of an alternative to Test::Aggregate called
http://www.oreilly.com/catalog/perlhks/
Live and work overseas - http://www.overseas-exile.com/
>
> From: Jonathan Swartz
>To: perl-qa
>Sent: Tuesday, 6 November 2012, 2:03
>Subject: preforking prove
>
>We have a large slow test suite
Hi Jonathan,
I like the idea. I rambled along similar lines a few years ago but
don't think I got past some preliminary code and $work has not had any
pressing need for such a thing in the meantime.
> * works well with parallel prove
How do you get from the single prefork into parallel test r
but a number of our
tests run into the caveats (e.g. they change singletons -- yes, this is not
ideal, but also not easily changeable).
I thought of an alternative to Test::Aggregate called "preforking prove", or
pfprove, which does the following:
* Accepts the same arguments as prove
13 matches
Mail list logo
