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]