On Mon, Jul 18, 2005 at 09:42:06AM -0400, Brett Sanger wrote:
> Currently I have a directory tree, and my testing consists of running
> prove on one .t file, a directory, or recursively over all. I don't
> seem to have a means of controlling the order of tests without using the
> shell. (i.e. "prove" will run the tests in whatever order it pleases.
> "prove *" will run them in asciibetical order) Is that true?
Simplest way to address this is to write a wrapper around prove. Then
you can sort any way you want or use Test::Manifest or whatever.
#!/usr/bin/perl -w
my @switches = grep /^-/, @ARGV;
my @tests = grep !/^-/, @ARGV;
my @tests = sort_files_however(@tests);
system("prove", @switches, @tests);
Or you can skip prove and just use Test::Harness::runtests(). prove is
just a fancy wrapper around that.
> There are some tests that I would love to have abort as soon as they
> fail. (If step 3 failed, then steps 4 and 5 are places I don't want to
> go) Is there a way to make prove do this? I skimmed the
> Test::Builder docs, in case I was going to have to roll my own
> prove-like tool, and didn't see an obvious call there either.
If you mean to abort the running of all further tests and test files, the
function you want is BAIL_OUT() which was added to Test::More in 0.60_01.
Its a very simple function and you can read about it here.
http://search.cpan.org/dist/Test-Harness/lib/Test/Harness/TAP.pod#Bail_out!
> I have some related tests. For example, to test the account management
> of our LDAP administration tools on the website, I have a test to create
> an account, test various edit options, then delete the account. (This
> is testing the create and delete as well, so I don't want to use an
> existing account). This means that I either write a very large,
> monolithic .t file which reduces my ability to testing single functions
> of the interface, or I write separate .t files for each function. In
> the latter case, I have to either be sure to run the create in the
> beginning and the delete at the end (see prove and order of tests at the
> start of this email) or I have to copy the create and delete code into
> each tests, making maintenance harder. Is there a common way to
> modularize code in test files? Is this just a "do" call?
Test::Class handles this well. Or you can write testing libraries,
throw them into t/lib, stick "use 't/lib'" into your .t files and use
your custom testing libraries as normal.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <[EMAIL PROTECTED]>
