It all depends on the size of the project.

http://svn.ali.as/cpan/trunk/PPI/t/

The PPI test suite is flat (with subdirectories for support and data files and a lib for test classes used by various tests) and yet it is quite a large project.

Then again, it's still only 5k-10k SLOC, and it's still a fairly straight forward structure (it's a plain module).

For truly large applications (using one 200k SLOC web application at work as an example) where the test suites are going to be highly diverse, then it's worth looking at breaking things up a bit.

For this project, the root of /t holds bootstrapping and general tests, with subdirectories to hold various classes of tests.

So the root checks all the modules compile, that they pass certain static analysis checks, that the configuration environment loads ok, and that all the external services identified by the configuration code exist and work.

The root is also where we put all the modules that we want to abort the entire test run on failure.

Then we have things like /t/db which contains all the tests for database sanity, DBI code, tests for the data model classes, etc.

Theres a /t/legacy that holds all the tests we've recovered from previous testing efforts that were later abandoned (this code base is over 10 years old now, and has gone through three generations of coding teams).

The /t/inline directory holds all the tests generated by Test::Inline (which we use to scatter tests for assumptions and what not through the codebase).

A /t/cp holds tests for one everything related to one particularly thorny section of the application.

Then theres /t/www for all the web interface testing, and t/dbmigrate for the tests for the database migration system we invented to deal with incredibly painstaking process of migrating an Oracle database that is too large and complex to be able to recreate from scratch.

And finally a /t/cpan to hold additional regression tests for specific bugs in CPAN modules we depend on. Some of these get submitted back to the original modules and removed later.

We also expect to aquire a /t/selenium directory and a /t/endecca (to test a specific third party search engine).

Within each directory, we still do numeric test names (01_foo.t, 02_bar.t).

Apart from straight forward separation of concerns this structure provides, it also makes life easier because you can use things like prove to test one subset of concerns (prove -r -b /t/db for example) without having to run the entire test suite, which for this application now runs out to 20+ minutes.

The directories also have the side-effect of acting as a basic semantic classification, they add more meaning to the test simply by looking at their file names, without having to read documentation.