Second things second: what do you feel comfortable with? Do things you are comfortable with. There is, after all, More Than One Way....

I tend to use the format "tnn-short-memory-jogging-phrase.t", to name my test-files. (ie: t00-basic-api.t, t05-extended-api.t, etc) Each file consists of all of the tests for a single module. I select 'nn' to have common functions grouped together in the prove() output or a directory listing. This works for me until the test-file for a single module gets 'too large', either logically (more that three or four logical/functional groupings) or physically (20+ one-line tests). (I basically follow the same principal that I use in deciding whether some code needs to be broken up into sub-routines -- Do I have to scroll up and down more than half-a-screen? Split it up!) When a test file gets too large, then I build the sub-directory for the module, move the test-harness into it, and refactor into several (much smaller) tnn-aaa.t files.

This has worked reasonably well for me over the years, but it's really a matter of personal taste. Just set things up so that it is easy for you to keep track of things during the Development process.

Also, remember that the Maintenance Programmer has to be able to pick up your test-file philosophy with out too much difficulty later. Make it easy for Them, and They are much more likely to Bless Your Name when they have to fix bugs and make functional changes.

I have to say that "whatever you feel comfortable with" isn't really an adequate answer to this kind of question: yeah there's lots of ways that things can be done, but some are more common that others, and other things being equal, it's going to be better to go with "standard practice" rather than making up a new way of doing things.

That said, Old_Gray_Bear's version of "standard practice" doesn't sound bad, and might not be a lot different from what I do, which is:

• Scatter "t" subdirectories throughout the code tree, with tests located near the code that they test. So the tests for Modular/Stuff.pm are in Modular/t.
• When first writing tests for Modular::Stuff, I name the test file Modular-Stuff.t. As the tests get more elaborate, I move the tests into numbered files (e.g. 00-init-Modular-Stuff.t, 01-db_access-Modular-Stuff.t, 02-data_munging-Modular-Stuff.t...).
• I put data files that tests use in a sub-directory of t called "dat", and I sometimes put shared code for these tests in modules located in a sub-directory called "lib".

And yes, prove -r is indeed the way to run it recursively. It really is a good ideas to get familar with prove, starting with the man page.

One of the nice things about "prove" by the way, is that you can narrow down the tests that you run with it by doing things like:

  prove '0*.t' '1*.t'
[download]

Lately I've been playing around with reserving blocks of numbers for tests-under-development that aren't expected to work yet. Tests named '0*.t' or '1*.t' had better work, or something has come unstuck, but a failure in tests named '2*.t' of '3*.t' just means you haven't finished something yet.

Take a look at Test::Class. It will make it Easier for you to manage your tests if they are are modules rather than sticking everything into one huge script or dozens of smaller test scripts.

I recommend subdirectories (and making prove recurse on them). More specifically, I recommend numbered subdirectories organized by functional area, where the numbering behaves correctly in standard globification.

For example, something like this:

000_basics/
            001_cpan-prerequisites.t
            002_database-bootstrap.t
            ...
100_orm/
            101_dbix-main-schema.t
            102_dbix-main-foo.t
            ...
200_main-classes/
            201_My-Special-Foo.t
            202_My-Class-Accessor-Lightspeed.t
            ...
300_parsing/
            301_xml-to-spaghetti.t
            302_unmelt-ice-cream.t
            ...
[download]

This gives you a few instant advantages:

• Your tests will be run in a useful order (ideally an order of ascending complexity).
• You can sensibly BAIL_OUT if you need to.
• Running only a group of related tests will be easy.
• If you need to later, you can have arbitrary levels of subdirectories without breaking the organization.
• If done right, it makes it easy to find tests.
• If done right, it makes it easy for new devs to know where to put their tests.

Anyway, setting up your test infrastructure is a Really Important Thing and I urge you to give it the same level of consideration you do to the rest of your system architecture. People touching your code later, including your future self, will thank you for it.

Oh yeah, and document the test architecture in case you're run over by an elephant and someone else has to figure it out.

isnt( $THEIR::obvious, $YOUR::obvious, "/obvious" );
[download]

Thanks for all the suggestions, it's always obviously a bit tricky trying to figure out how to arrange things when you've no idea how large a project is going to be.

This one is no doubt gonna get VERY large, re-factoring code that's over 8 years old into sensible modules.

Thanks again!

Of course it will.

prove -r

Why not make up an answer?