Should I, or can I, break out the other tests into separate files in an attempt to modularize? Or is there a cunning way to run groups of tests from a superior file?

It sounds like you need to do some things manually between test1 and test2? If so, then use Term::Readkey or some other things of receiving input from the tester that it is time to continue.

So no, I don't think skip is what you want. I think you basically would have:

0-system_check.t
1-read_user_input.t
2-retest_on_files.t
[download]

Hmm. Well, now I understand why the test files are numbered -- so they're done in a particular order.

But I think this doesn't help me with the question that I have about modularizing the files. In addition, The 'retest' on your list would not necessarily include the 'system_check' tests. OK, well, I think I have enough information to go ahead and try this out.

And I'll use the diag method to inform the user of what's going on and perhaps get them to run some additional tests with parameter values (document ID of a specific test file, for example).

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

source
  bin
  lib
  t
    data
[download]

The lib directory (and below) contains the source files (for My::Module::Name in My/Module/Name.pm).

The t directory contains all the test files, one for each class (e.g. My-Module-Name.t). Sometimes there are extra files for some classes if some aspects of it need more tests (e.g. My-Module-Name-convert.t). I don't care about the order of tests being run; if something breaks, it's usually easy to figure out the root cause of the breakage.

The t/data directory contains data used by the tests.

Basic classes are easily tested by themselves. Other classes have dependencies, and then it becomes necessary to set up an environment for them to work. I do this in each file that needs it. Sometimes it becomes very repetitive, and it may be a good idea to refactor the setup test code into a class (e.g. SetupFoo.pm) which I put in the t directory and use from the .t files.

For complicated chains of depdent classes or external resources like web server access or time, I find it useful to fake it with Test::MockObject. WWW::Mechanize::Cached is also useful to fake web sites.

Well, that's how I do it.

/J

Putting this all in one large test script is asking for trouble: after a while you would need a test to check the tests!.

• Test::MockObject for general object mocking
• Test::MockModule for general module mocking
• DBD::Mock for mocking database connections

They will help decouple the various components of your system so you can focus on testing one specific piece. This will also allow you to simulate failures that you can't reliably create so you can test your error-handling in a safe and repeatable fashion.

I can offer several thoughts from my own practices -- no claim that any is right (clearly I don't even have a really consistent standard), but one or more of them may resonate for you.

• For a really simple module, all the tests go in one file in the t/ directory
• For utility modules, I tend to break out test scripts somewhat ad hoc to test different types of functionality. (You might think of this as testing 'use cases')
• For a distribution with lots of classes/subclasses, I've generally gone with one test file per module, testing whatever is unique/different about that module
• In one case, with a really complicated object hierarchy, I've set up subdirectories within t/ to mimic my object hierarchy and customized the Build.PL to search t/ recursively.
• If I find myself with a lot of redundant setup code, I create a "TestHelper.pm" module in the t/ directory and have my test scripts load that. (Though I recently learned about Test::Class and think it might be a better approach for that kind of thing.)

Generally, I consider test scripts cheap and don't hesistate to create a new one to test a narrow set of functionality. That said, I try to keep related tests grouped together in one file.

Also, in your core toolkit of Test modules, make sure you look at Test::Exception. I use it so frequently that my default .t template automatically sticks that in along with Test::More. (And if you're doing a lot of floating-point math, you might appreciate my own Test::Number::Delta, too.)

 ___ _  _  __  __  ___  ___ ___
(_-<| || |/ _|/ _|/ -_)(_-<(_-<
/__/ \_,_|\__|\__|\___|/__//__/
[download]

  __        _  _
 / _| __ _ (_)| | _  _  _ _  ___
|  _|/ _` || || || || || '_|/ -_)
|_|  \__,_||_||_| \_,_||_|  \___|
[download]

#testname      testgroup
base.t         core
dvd_core.t     core
dvd_mount.t    dvdread
dvd_read.t     dvdread
dvd_burn.t     dvdwrite
tape_core.t    core
tape_mount.t   taperead
tape_read.t    taperead
tape_write.t   tapewrite
[download]

This described the test order (from top to bottom) and the test group name. The user would invoke the script like "test.pl taperead" (or via make) which would run the non-hardware tests ("core") and then test mounting and reading (but not writing) a tape. That way I could just run the tests I wanted (some were very time consuming) and I didn't have to put checks in the various scripts for hardware existence and mess with embedding Test::More SKIP sections everywhere. Obviously you can get sophisticated here wrt groupings, but it's pretty easy to set up a basic group dependency list with a hash.