+1 from me! I like Test::Class and would welcome a Moose-ish variety.
On Dec 12, 2012, at 9:51 AM, Ovid wrote:
> Hi all,
>
> People keep asking me how to properly integrate Moose with Test::Class. I
> know about Test::Able and some alternatives, but I *generally* like
> Test::Class's interfac
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
> 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 las
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
On Nov 6, 2012, at 9:58 AM, Jonathan Swartz wrote:
> miyagawa sent me this proof of concept - using fork, not star
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
hings.
On Nov 5, 2012, at 5:03 PM, Jonathan Swartz wrote:
> We have a large slow test suite at work (Test::Class, 225 classes, about 45
> minutes run time). Many of the tests start by loading a bunch of the same
> modules. Obviously we could speed things up if we could share that l
We have a large slow test suite at work (Test::Class, 225 classes, about 45
minutes run time). Many of the tests start by loading a bunch of the same
modules. Obviously we could speed things up if we could share that loading cost.
I'm aware of Test::Aggregate and Test::Aggregate::Nested, but a n
;Mark Morgan"
wrote:
> On Mon, Aug 24, 2009 at 6:37 PM, Jonathan Swartz wrote:
> > Yes, getting the pid from each process launch is not the problem - it's
> > more of a wish that I could do this automagically somehow, instead of
> > having to collect all the pids somewhere.
move any temp directories that they may have been using.
> Encapsulating that work into a single test is also nice as you can
> simply call that test as part of 'make [dist]clean' :)
>
> --
> Greg Sabino Mullane g...@endpoint.com
> End Point Corporation
> PGP Key: 0x14964AC8
>
--
Jonathan Swartz
jonswa...@fastmail.net
I have a series of test scripts that launches server subprocesses of
different kinds - httpd, HTTP::Server::Simple, etc. A test script
might launch multiple instances of each type of server. I'd like to
behave well and kill all these children before the test exits. But
it's a pain to keep t
On 07/31/2009 01:51 PM, Jonathan Swartz wrote:
There are certain tests in my distribution that I don't want end
users
to run. I want to run them during development, and I also want anyone
else contributing to the distribution to run them. These are
typically
related to static analysis o
Justin Devuyst kindly pointed me to
Module::Install::AuthorTests
which appears to have the desired behavior if one is using
Module::Install (which I happen to be). Thanks again.
Jon
On Jul 31, 2009, at 11:32 AM, Jonathan Swartz wrote:
On 07/31/2009 01:51 PM, Jonathan Swartz wrote
There are certain tests in my distribution that I don't want end users
to run. I want to run them during development, and I also want anyone
else contributing to the distribution to run them. These are typically
related to static analysis of the code, e.g. perl critic, perl tidy
and pod che
Jonathan Swartz wrote:
2) I have to compute the right exception paths. Doing "use lib
qw(blib/lib blib/arch)" as you suggest would only work if the tests
were
run from the main directory. e.g. If I'm in the t/ directory and do
"perl -I../lib foo.t", as I do sometimes,
On Wed, May 06, 2009 at 12:15:38PM -0400, David Golden wrote:
On Wed, May 6, 2009 at 12:05 PM, David Cantrell > wrote:
That's true, but this isn't just about testing libs - it's any
lib I
might delete from the distribution.
You want Devel::Hide.
I think the original question was about catchin
That's true, but this isn't just about testing libs - it's any lib I might
delete from the distribution.
-Original Message-
From: Michael Peters
Date: Wednesday, May 6, 2009 6:22 am
Subject: Re: masking installed versions when running tests
To: Jonathan Swartz
CC: per
When I run tests for a distribution, say CHI, I'd like to be able to
ignore any installed versions of CHI's modules. That way I know I'm
testing it as if it were a fresh install.
In the latest version I deleted a necessary module, CHI/t/
Multilevel.pm, from the distribution, but "make test"
I ended up going with this solution. Incidentally, it is runtests(),
and I think the first 1; is unnecessary (at least it seems to be for
me).
Thanks!
Jon
On Oct 26, 2007, at 10:39 AM, Tom Heady wrote:
Jonathan Swartz wrote:
...
I'd like to avoid actually running a single scrip
chromatic wrote:
On Friday 26 October 2007 13:05:14 Tom Heady wrote:
The method does require a single file per class, and loading perl
for
each of those files. If you are trying to avoid that it's not
going to
help.
... and if that's the slowest part of 45-minute test runs, color
me
So this is a single file? And when you say you are getting around the
problem, you mean having to define a whole other script per class?
Because it still looks like you have to launch Perl and load your
modules for every test class.
On Oct 26, 2007, at 10:39 AM, Tom Heady wrote:
Jonathan
On Oct 26, 2007, at 9:39 AM, Andy Armstrong wrote:
On 26 Oct 2007, at 17:36, Jonathan Swartz wrote:
Would it be easier to write a subclass of TAP::Harness and use
runtests, instead of Test::Harness and prove? I confess that I'm
still a little confused about the relationship between th
On Oct 26, 2007, at 6:50 AM, Michael Peters wrote:
We use Test::Class a lot too and we do indeed write a separate
script for each
testing module.
I dislike the latter solution for its inefficiency, as Perl
and all our common modules would have to be loaded many times. Our
test suite already
We use Test::Class for all our tests, with a single script (_t.pl)
that automatically loads and runs all test classes.
Unfortunately, with prove and the standard test harness, this causes
test output in which all tests are listed under a single script.
/home/swartz/env/hm/lib/HM/t/_t...
On Aug 10, 2007, at 8:22 AM, Ovid wrote:
--- Andy Lester <[EMAIL PROTECTED]> wrote:
I had actually submitted a patch to 'prove' a long time ago which
allowed prove to accept a pattern and only run tests whose
filenames
match said pattern. It was never applied, so I assume Andy has
some
r
On Aug 10, 2007, at 3:20 AM, Ovid wrote:
--- Jonathan Swartz <[EMAIL PROTECTED]> wrote:
I'm wondering if any Test::Class (or Test::Unit, etc.) users out
there have yearned for a more convenient way to specify which classes
and methods to run, and if there's any reasonable
Hello,
I'm in the process of switching over to Test::Class and prove, after
naively inventing my own versions of these. :)
One feature I had with my solution was command-line switches to
choose which classes and methods to run. For example,
runtests.pl -t Session -m basic
This would
27 matches
Mail list logo
