As chromatic says, if I'm testing a single, small module, I usually just use a single .t file. I would rename 00-load.t to 00-Foo_Bar.t and put all my tests in it.
If it's multi-module or just complex, I break up the test files by related functionality. Since I tend to favor test-driven development, I find that I create a new test file for each new feature I implement. As soon as I'm "done" with a feature and on to the next, I create a new test file.
Breaking it up like this means that I'm usually only running the tests for the current feature under development, which keeps the testing time down. Then periodically, I run the full test suite to make sure I didn't break anything else in the process.
Often, I find that some tests wind up being a loop over a bunch of test data in a datastructure. (See Re^2: Wanted, more simple tutorials on testing for an example of this.) I that case, I usually make a separate .t file for each datastructure.
As a side note, if I'm thinking of distributing this to CPAN, I also make the boilerplate pod.t and pod-coverage.t optional by adding something like this at the top:
use Test::More;
plan skip_all => "Skipping author tests" if not $ENV{AUTHOR_TESTING};
Not everyone agrees with this approach, but that's how I do it.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
|