Re: NAME field
Good point. Any suggestions? With this module it's possible to have 1 Conf frontend using one of the provided backends: String, File, SQL, INI for now, but later probably Win32::Registry, maybe Wx::Config. I wasn't really concerned about namespaces when I wrote this. I like modules with short names. Anyway It would be: Config Config::String Config::File Config::SQL Config::INI (...) Config::Win32::Registry Config::wxConfig etc. Randy W. Sims wrote: On 4/1/2004 5:25 AM, Hans Oesterholt-Dijkema wrote: Dear All, I'm just wondering. I've uploaded a few modules last days, of which: Conf-0.06 Conf-SQL-0.05 Conf-INI-0.03 Why? There are already several namespaces where configuration type modules are located, primarily Config::*. Why do you feel the need to place your modules in a different namespace? Randy.
running tests
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.
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 Atest1.t, Bsometest.t, but it seems hokey and I'm not sure it would work on all systems. Look at Test::Manifest by brian d foy. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
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 rigorously in a previous test. For instance the first would be an error reporting function which should work no matter what (but I don't want to test it in every test file), then there are a class of functions for querying the system which only rely on error function that works, then there are establishing a template and using the template to set attributes, then there is job submission and synchronization, then there is job problem detection, then there is alternate job synchronization, then blah, blah... But the tests get more complicated in progression so it will need to rely on previous tests having suceeded, OR write one giant test script. I just thought it would be more useful to the user to catch trivial problems in the first tests, and more complicated problems in later tests. However, Test::Manifest seems not to be a part of core perl, so if I used that it would be one more prereq module I'd need, so that is something of a draw back. - Original Message - From: Andy Lester [EMAIL PROTECTED] To: Tim Harsch [EMAIL 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 Atest1.t, Bsometest.t, but it seems hokey and I'm not sure it would work on all systems. Also, WHY do you want them to run in a predefined order? Are you doing setup in one, running some other tests, and then shutdown in another? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: running tests
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 would work on all systems. I think a lot of us just use numeric prefixes to control the order: 01_ini.t 02_scalar.t 03_list.t ... etc. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ Live Free or Die, the Only Way to Live -- NH State Motto
Re: running tests
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, 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 would work on all systems. I think a lot of us just use numeric prefixes to control the order: 01_ini.t 02_scalar.t 03_list.t ... etc. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ Live Free or Die, the Only Way to Live -- NH State Motto
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 everything as independent as possible, so that I can run a single test (using prove) as part of my development process. Write the test. Code the code. Run the test. Fix the code. Run the test. etc. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: running tests
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 to make everything as independent as possible, so that I can run a single test (using prove) as part of my development process. Andy, So how do you recommend handling the case where some tests depends on other things being in place? 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. 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. Is that what you do, Andy? Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
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, it creates it. If it needs to delete the data, then it deletes it. We also have some tests that watch for leftover bad data (customers that have a special status of Z are ones that only exist for testing, so if they're in the DB, we know that something didn't clean up) xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: running tests
I don't know what you mean by using prove? And, you're right, that is the best way to develop a module I think. Some tests cannot be run unless certain functions run to setup the state, so I want to formally test the prereq functions to make sure they are returning the correct number of return values etc, in the earlier trivial tests, but in the subsequent tests that concentrate on a different subset of functions they will need to use the previous functions to set up the state, so I only want to test that the function succeeded in setting up the state, but not that it is capable of returning the correct number of return values and working under every imaginable legitimate permutation yet again. I don't know if I'm making sense. - Original Message - From: Andy Lester [EMAIL PROTECTED] To: Tim Harsch [EMAIL PROTECTED] Cc: Perl Mod Authors [EMAIL PROTECTED] Sent: Friday, 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 everything as independent as possible, so that I can run a single test (using prove) as part of my development process. Write the test. Code the code. Run the test. Fix the code. Run the test. etc. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: running tests
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 the database, it opens one. If it needs test data in the database, it creates it. If it needs to delete the data, then it deletes it. 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. It seems reasonable to break with the ideal of self contained tests a bit and put shared test setup/tearcode code into a re-usable testing module. (which itself might have a single set of tests run against it). Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
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 ideal of self contained tests a bit and put shared test setup/tearcode code into a re-usable testing module. (which itself might have a single set of tests run against it). And in many cases we do that as well. The problem with that is knowing where the test counts are incremented. We also have a module TW::Mechanize (TW is our app) that subclasses WWW::Mechanize and includes TW-specifc object methods. Now, instead of: $mech-get( $url ); html_ok( $mech-content, HTML is OK ); we do $mech-get( $url ); $mech-html_ok( HTML is OK ); which means that if we want to do other HTML checking, it's encapsulated in the html_ok() method. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: running tests
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 rigamarole.
I use 'prove' as well and find it to be very useful. Here's a command I
mind use to run all the 'base' tests, plus those for milestones 1
through 3:
prove -I../perllib --ext=.pl base m{1,2,3}
Then if one fails, I can zero in one it and turn on the verbose option:
prove -v -I../perllib m1/shelter_add_edit_func.pl
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark StosbergPrincipal Developer
[EMAIL PROTECTED] Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
Re: running tests
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 are intentionally painful. It seems reasonable to break with the ideal of self contained tests a bit and put shared test setup/tearcode code into a re-usable testing module. (which itself might have a single set of tests run against it). Refactor the duplicated code. Most of my Devel::Cover tests look something like: use Devel::Cover::Test; my $test = Devel::Cover::Test-new(trivial); $test-run_test And my Gedcom tests: use Basic (resolve = unresolve_xrefs, read_only = 0); Coding tests is just like coding anything else. Possibly more so, because bugs in the tests themselves are a real pain. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: running tests
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 infrastructure to help you might want to take a look at bias type=author Test::Class /bias. It provides a framework for creating setup/teardown routines that run around your tests allowing you to make test fixtures. Also, if there were dependencies between modules Foo and Bar I'd also try to create mocks for Foo in the Bar tests, and for Bar in the Foo tests - so I can run each test suite independently. Adrian
Re: running tests
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 don't care how long things take. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: NAME field
Hans Oesterholt-Dijkema wrote: Good point. Any suggestions? With this module it's possible to have 1 Conf frontend using one of the provided backends: String, File, SQL, INI for now, but later probably Win32::Registry, maybe Wx::Config. I wasn't really concerned about namespaces when I wrote this. I like modules with short names. Anyway It would be: Config Config::String Config::File Config::SQL Config::INI (...) Config::Win32::Registry Config::wxConfig etc. Sorry, Config is a core module (see perldoc Config). Look at other modules that do what you want: Browse by catagory: http://search.cpan.org/modlist/Option_Parameter_Config_Processing Browse by module name: http://www.cpan.org/modules/by-module/Config/ Search for keywords: http://search.cpan.org/search?query=config Those are just examples, you may find more with different search keywords, etc. There are a lot of modules out there that handle config files. Research what is available. If possible use or enhance an existing module. If you really believe you have a unique module, the above research will help suggest an appropriate name. I'm not trying to discourage you, but there is already a lot of repitition and junk on CPAN. It's an authors responsibility to do the research before tossing another module on the heap. My suggestion for a name (if you find that your module offers something unique) would be Config::something, where something hints that it's a front end to multiple output formats, maybe Multi Regards, Randy.
Re: running tests
Not concerned with wasted time really (at least in this case). Just seems more logical to me that if early tests fail it is more of a clue to the user that something fundamental to the installation was wrong, whereas in later tests is seems more of a clue that perhaps something architecture dependant isn't working in the module, or who knows what else. Sort of a severity measure I take it back, I suppose time is a concern: here's why... My module provides an API for distributing jobs via a DRM (Distributed Resource Manager) like SGE or Condor. A busy cluster may take a while for the job to leave to waiting queue, transfer to a running state, and complete. So I spose my tests in theory could take weeks to complete ( I guess I better code in an option to not actually distribute jobs), but even just communicating to the master node (as early tests would do), depending on how the cluster is configured and how busy the network is, could take awhile on a busy network. Sorta similiar I imagine, for a database module, what if the database is heavily loaded? I'll post my module docs to help provide context to the discussion. - Original Message - From: Andy Lester [EMAIL 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 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 don't care how long things take. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: running tests
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 effort. 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 department gets notified. # Crontab entries 0 * * * * smokebot HEAD [EMAIL PROTECTED] 30 * * * * smokebot cp2004-branch [EMAIL PROTECTED] Note that it pulls the main trunk to do testing on the hour, and the branch for development on the half-hour. And here's the smokebot script # The script proper #!/bin/sh if [ $# -lt 2 ] then echo Must pass at least a branch, and one email address, echo plus any parms to echo pass to smoke. exit 1 fi REV=$1 shift MAIL=$1 shift cd $TMP DIR=tw FULLPATH=$TMP/$DIR # This assumes you have already logged in once as anoncvs # so that the password is in your ~/.cvspass file. cvs -d/home/cvs -Q co -d $DIR -r $REV tw /dev/null TWROOT=$FULLPATH export TWROOT /home/smoke/tw/Dev/devapache stop/dev/null 21 /home/smoke/tw/Dev/devapache start /home/smoke/smoke.out 21 cd $TWROOT smoke $@ /home/smoke/smoke.out 21 grep -i ^Failed /home/smoke/smoke.out /home/smoke/smoke.out.fail if [ -s /home/smoke/smoke.out.fail ] then STATUS=FAILED mail -sSmoke $REV $@ $STATUS `date` $MAIL /home/smoke/smoke.out else STATUS=passed fi /home/smoke/tw/Dev/devapache stop /home/smoke/smoke.out 21 -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: NAME field
I know, Config.pm would not be a good thing to replace . I've been looking around quite a lot lately. And I must say, I didn't find a Configuration module that provided a single interface to multiple backends. Although many folks say a lot about abstraction and layering, (I would think it common practice). I found only one that comes near. But it's part of OpenInteract and not quite the same. I think Config::Multi is not a bad name for this module. But Config::Front would also be a name. I think it can have it's uses, as it is in fact a module that only forms a front end to other config modules and unifies the API (to a very simple key/value form). I'm writing it because I want to be able to write unix/perl/win32 registry through one interface. So which would be better: Config::Multi Config::Front Config::End Config::Frontend I personally am quite charmed about the last one. Best whishes, Hans Oesterholt. Randy W. Sims wrote: Hans Oesterholt-Dijkema wrote: Good point. Any suggestions? With this module it's possible to have 1 Conf frontend using one of the provided backends: String, File, SQL, INI for now, but later probably Win32::Registry, maybe Wx::Config. I wasn't really concerned about namespaces when I wrote this. I like modules with short names. Anyway It would be: Config Config::String Config::File Config::SQL Config::INI (...) Config::Win32::Registry Config::wxConfig etc. Sorry, Config is a core module (see perldoc Config). Look at other modules that do what you want: Browse by catagory: http://search.cpan.org/modlist/Option_Parameter_Config_Processing Browse by module name: http://www.cpan.org/modules/by-module/Config/ Search for keywords: http://search.cpan.org/search?query=config Those are just examples, you may find more with different search keywords, etc. There are a lot of modules out there that handle config "files". Research what is available. If possible use or enhance an existing module. If you really believe you have a unique module, the above research will help suggest an appropriate name. I'm not trying to discourage you, but there is already a lot of repitition and "junk" on CPAN. It's an authors responsibility to do the research before tossing another module on the heap. My suggestion for a name (if you find that your module offers something unique) would be Config::something, where something hints that it's a front end to multiple output formats, maybe Multi Regards, Randy. -- Best regards, Hans Oesterholt-Dijkema inline: wink_n.gif
Re: running tests
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 department gets notified. Very helpful Andy. smoke $@ /home/smoke/smoke.out 21 And what does the inside of this 'smoke' script look like? Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Schedule::DRMAAc docs
Here are the docs for the module I plan to release in the next week or so.
Any comments appreciated.
Title: DRMAAc.pm
NAME
Schedule::DRMAAc - Perl wrapper of the C binding of the DRMAA
(Distributed Resource Managment Application API) specification.
SYNOPSIS
This module is a Perl wrapper for the C binding of the DRMAA
specification, which allows for the submission and control of jobs to one
or more Distributed Resource Management (DRM) systems (eg. SGE, Condor,
etc. ).
use DRMAA qw/ :all /;
( $error, $diagnosis ) = drmaa_init( undef );
die drmaa_strerror( $error ) . ``\n'' . $diagnosis if $error;
( $error, $jt, $diagnosis ) =
drmaa_allocate_job_template()
;
die drmaa_strerror( $error ) . ``\n'' . $diagnosis if $error;
( $error, $diagnosis ) = drmaa_set_attribute( $jt, $DRMAA_REMOTE_COMMAND, '/bin/sleep' );
die drmaa_strerror( $error ) . ``\n'' . $diagnosis if $error;
( $error, $diagnosis ) = drmaa_set_vector_attribute( $jt, $DRMAA_V_ARGV, [ ``1'' ] ); # 1st argv param = 1 (to run for 1 second)
die drmaa_strerror( $error ) . ``\n'' . $diagnosis if $error;
( $error, $jobid, $diagnosis ) = drmaa_run_job( $jt );
die drmaa_strerror( $error ) . ``\n'' . $diagnosis if $error;
my @job_constant = ( $DRMAA_JOB_IDS_SESSION_ALL );
( $error, $diagnosis ) = drmaa_synchronize( \@job_constant , $DRMAA_TIMEOUT_WAIT_FOREVER, 0 );
die drmaa_strerror( $error ) . ``\n'' . $diagnosis if $error;
( $error, $diagnosis ) = drmaa_delete_job_template( $jt );
die drmaa_strerror( $error ) . ``\n'' . $diagnosis if $error;
AUTHOR
Tim Harsch [EMAIL PROTECTED]
NOTES
This module was created using SWIG on the drmaa.h file provided in SGE
version 6.0. As such, certain behaviours of the module were decided by
either the unerlying DRMAA library, or by SWIG's method of generating Perl
to C wrapping functionality. Needless, to say the design of this Perl
module's API is somewhat constrained by the underlying C library.
Nearly every function listed below has an $error and a $diagnosis
returned from it. In nearly all cases $error will be
$DRMAA_ERRNO_SUCCESS, and an error otherwise. The $error can be looked up
via the drmaa_strerror function. And, $diagnosis provides further
problem hints.
A useful line for checking the success of most of these functions is:
die drmaa_strerror( $error ) . ``\n$diagnosis'' if $error;
Because $error and $diagnosis are trivial they will not be mentioned again
unless special meaning needs to be clarified.
This documentation was created using the DRMAA spec, SGE drmma.h and
drmaa.c source files as a reference. Any ambiguities here can be cleared
up by visiting those.
DESCRIPTION
vector attributes ( to be used with drmaa_set_vector_attribute and
related functions )
$DRMAA_V_ARGV( vector of strings )
These parameters are passed as arguments to the job.
$DRMAA_V_ENV( vector of strings )
The environment values that define the remote environment. Each string
complies with the format name=value. The values override the remote
environment values if there are collisions.
If the above is not possible, it is implementation dependent.
$DRMAA_V_EMAIL( vector of strings )
The email address(es) used to report the job completion and status.
non-vector attributes ( to be used with drmaa_set_attribute and
related functions )
$DRMAA_REMOTE_COMMAND ( String )
The name (and optional path) of the job. If a relative path is used,
it should be relative to $DRMAA_WD.
$DRMAA_JS_STATE ( ``drmaa_active'' or ``drmaa_hold'' )
A beginning state for the job to start as on the exec host
$DRMAA_WD ( String )
The directory where the job is executed
$DRMAA_JOB_CATEGORY ( String )
DRM specific value for site-specific policies
$DRMAA_NATIVE_SPECIFICATION ( String )
DRM specific value for site-specific policies"
$DRMAA_BLOCK_EMAIL ( 0 or 1 )
Send or Block email notifications from the DRM
$DRMAA_START_TIME CC]YY/]MM/]DD] hh:mm[:ss] [{-|+}UU:uu]
The earliest time when the job may be eligible to be run. The time
format is as follows:
CC]YY/]MM/]DD] hh:mm[:ss] [{-|+}UU:uu]
CC is the first two digits of the year (century-1)
YY is the last two digits of the year
MM is the two digits of the month [01,12]
DD is the two-digit day of the month [01,31]
hh is the two-digit hour of the day [00,23]
mm is the two-digit minute of the day [00,59]
ss is the two-digit second of the minute [00,61]
UU is the two-digit hours since (before) UTC
uu is the two-digit minutes since (before) UTC
If the optional UTC-offset is not specified, the offset
associated with the local timezone will be used. If the day (DD) is not
specified, the current day
Re: running tests
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
Re: running tests
On Fri, Apr 02, 2004 at 02:51:11PM -0600, Andy Lester wrote: 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 don't care how long things take. It's more the time spent looking at the test results rather than the time spent running the tests. So actually it's the result presentation order that matters. Basically you want to consider the failure reports starting from the lowest level as these may make the higher level failures irrelevant. The order the tests actually ran in should be irrelevant to the outcome but if you're running from the command line the run order determines the presentation order. 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 to save even 30 seconds by killing the suite if a low level test fails, F
Re: running tests
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 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 make test suite. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: running tests
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] = www.petdance.com = AIM:petdance
