On Apr 2, 2004, at 4:59 PM, Andy Lester wrote:
Sure, but even better is to run only the tests that need to be run,
which is a key part of prove. You can run prove -Mblib t/mytest.t
instead of the entire make test suite.
When I'm using Module::Build, I do this:
Build test --test_files
* Andy Lester andy at petdance.com [2004/04/02 16:59]:
Sure, but even better is to run only the tests that need to be run,
which is a key part of prove. You can run prove -Mblib t/mytest.t
instead of the entire make test suite.
$ make test TEST_FILES=t/mytest.t
(darren)
--
An idea is not
$ make test TEST_FILES=t/mytest.t
Sure, and you can turn on HARNESS_VERBOSE to get the raw output of the
.t file. prove puts all that stuff behind easy command-line switches,
and lets you specify wildcards, and lets you specify a directory that
implicitly does all the *.t within the
[EMAIL PROTECTED] (Andy Lester) writes:
Sure, and you can turn on HARNESS_VERBOSE to get the raw output of the
.t file. prove puts all that stuff behind easy command-line switches,
and lets you specify wildcards, and lets you specify a directory that
implicitly does all the *.t within the
On Mon, Apr 05, 2004 at 05:05:34PM +0100, Simon Cozens wrote:
[EMAIL PROTECTED] (Andy Lester) writes:
Sure, and you can turn on HARNESS_VERBOSE to get the raw output of the
.t file. prove puts all that stuff behind easy command-line switches,
and lets you specify wildcards, and lets you
there's 'prove -h' and 'perldoc prove', making things much easier to
learn and lookup.
And, for that matter, prove --man == perldoc prove
xoa
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
level). Also when running tests interactively it's nice to be able to
save even 30 seconds by killing the suite if a low level test fails,
Sure, but even better is to run only the tests that need to be run,
which is a key part of prove. You can run prove -Mblib t/mytest.t
instead of the entire
On Sat, Apr 03, 2004 at 01:37:03AM +0200, Paul Johnson wrote:
Coming soon to Devel::Cover (well, on my TODO list anyway):
- Provide an optimal test ordering as far as coverage is concerned - ie
tests which provide a large increase in coverage in a short time are
preferred. There
Hi all,
If I have several test files in my test suite, is there a way to get them to
run in a predefined order when the user runs make test? I realize I could
name them alphabetically like Atest1.t, Bsometest.t, but it seems hokey
and I'm not sure it would work on all systems.
If I have several test files in my test suite, is there a way to get them to
run in a predefined order when the user runs make test? I realize I could
name them alphabetically like Atest1.t, Bsometest.t, but it seems hokey
and I'm not sure it would work on all systems.
Look at Test::Manifest
PROTECTED]
Cc: Perl Mod Authors [EMAIL PROTECTED]
Sent: Friday, April 02, 2004 9:59 AM
Subject: Re: running tests
If I have several test files in my test suite, is there a way to get
them to
run in a predefined order when the user runs make test? I realize I
could
name them alphabetically like
On Fri, 2 Apr 2004, Tim Harsch wrote:
Hi all,
If I have several test files in my test suite, is there a way to get them to
run in a predefined order when the user runs make test? I realize I could
name them alphabetically like Atest1.t, Bsometest.t, but it seems hokey
and I'm not sure it
That seems a better idea than A, B etc. I'll just use that. Thanks!
- Original Message -
From: Arthur Corliss [EMAIL PROTECTED]
To: Tim Harsch [EMAIL PROTECTED]
Cc: Perl Mod Authors [EMAIL PROTECTED]
Sent: Friday, April 02, 2004 10:32 AM
Subject: Re: running tests
On Fri, 2 Apr 2004
No. But there are certain classes of functions of the module that don't
work until others have been run. So others should have been tested
So some tests are setting up other ones, then?
One of my goals when writing tests is to make everything as independent
as possible, so that I can run a
On Fri, Apr 02, 2004 at 01:52:12PM -0600, Andy Lester wrote:
No. But there are certain classes of functions of the module that don't
work until others have been run. So others should have been tested
So some tests are setting up other ones, then?
One of my goals when writing tests is
For example, with DBD::Pg, a lot of tests depend on having test data in
the database, and having the database connection working and open.
Every one of our *.t and *.phpt files is self-contained. If it needs a
connection to the database, it opens one. If it needs test data in the
database,
, April 02, 2004 11:52 AM
Subject: Re: running tests
No. But there are certain classes of functions of the module that don't
work until others have been run. So others should have been tested
So some tests are setting up other ones, then?
One of my goals when writing tests is to make
On Fri, Apr 02, 2004 at 02:02:24PM -0600, Andy Lester wrote:
For example, with DBD::Pg, a lot of tests depend on having test data in
the database, and having the database connection working and open.
Every one of our *.t and *.phpt files is self-contained. If it needs a
connection to
Does that mean the test scripts are full of copy/paste coding?
So if there is a bug in the test up routine, it would be propagated
everywhere.
That is indeed potentially the case. OTOH, once the code works, then
changes to it are intentionally painful.
It seems reasonable to break with the
On Fri, Apr 02, 2004 at 02:12:46PM -0600, Andy Lester wrote:
I don't know what you mean by using prove?
prove is a command-line utility that ships with Test::Harness. It
allows you to run a specific test or tests, as specified on the command
line, without having to go through the make test
On Fri, Apr 02, 2004 at 02:19:03PM -0600, Andy Lester wrote:
Does that mean the test scripts are full of copy/paste coding?
So if there is a bug in the test up routine, it would be propagated
everywhere.
That is indeed potentially the case. OTOH, once the code works, then
changes to it
On 2 Apr 2004, at 20:59, Mark Stosberg wrote:
[snip]
One idea would seem to be have a testing module that provides the
setup and tear-down functionality. Then each individual test could
load the testing module, and setup and teardown for itself.
[snip]
That would be my approach. If you want some
coded correctly. So it's desirable to see the results of the lower level
tests first because running the higer level tests could be a waste of time.
But how often does that happen? Why bother coding to optimize the
failures?
Besides, if you have a smokebot to run the tests for you, then you
PROTECTED]
To: Fergal Daly [EMAIL PROTECTED]
Cc: Tim Harsch [EMAIL PROTECTED]; Perl Mod Authors
[EMAIL PROTECTED]
Sent: Friday, April 02, 2004 12:51 PM
Subject: Re: running tests
coded correctly. So it's desirable to see the results of the lower level
tests first because running the higer
Beats me what a smokebot is. Presumably it's something I should
know about. But I only have so many hours in the day to know about everything,
so simple and not requiring effort is better, for me anyway.
I think you'll find that having a smokebot adds to the simple and not
requiring
On Fri, Apr 02, 2004 at 03:48:12PM -0600, Andy Lester wrote:
A smokebot is a script that runs your test suite at regular intervals,
kicked off by cron. It checks out a given CVS branch, and then runs the
entire test suite. For us, it runs once an hour, and if any tests fail,
the entire
smoke $@ /home/smoke/smoke.out 21
And what does the inside of this 'smoke' script look like?
It's just prove. An FLR-specific version of prove, but it's just prove.
xoa
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
presumably run the tests (depends on the
size of the suite I suppose) before a checkin and it's convenient to know
that the first failure message you see if the most relevant (ie at the
lowest level). Also when running tests interactively it's nice to be able to
save even 30 seconds by killing
Even if you have a smoke bot, you presumably run the tests (depends on the
size of the suite I suppose) before a checkin and it's convenient to know
that the first failure message you see if the most relevant (ie at the
lowest level). Also when running tests interactively it's nice to be able
On Sat, Apr 03, 2004 at 01:37:03AM +0200, Paul Johnson ([EMAIL PROTECTED]) wrote:
Coming soon to Devel::Cover (well, on my TODO list anyway):
Could we pleease get it to run under -T first, though?
Then I could do coverage testing on Test::Harness!
xoa
--
Andy Lester = [EMAIL PROTECTED] =
30 matches
Mail list logo
