The easiest thing to do is look at a few modules on CPAN and see how they do it. Typically you'll find lots of *.t files in the t/ directory, sometimes they'll be prefixed with numbers so they'll execute in a predictable order. (Whether that's a good idea is a different post.) But whatever you do try and make the test names as descriptive as you can.

Assuming each module is reasonably separate and reasonably small, I usually start by creating one test file for each module.

If the distribution as a whole represents a reasonably complete application, I try to include customer-level tests as well that exercise the main user-visible features on their own... but that's a different story from what you're asking.

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.

Have each .t file exercise a specific part of your functionality. It's ok to have a lot of test files if your distro has a lot of use cases. For example, DBM::Deep is up to 29 test files and I'll be adding probably 3-4 more in the next month.

It's also ok to have only 2-3 testcases in a .t file. Remember - each .t file is run in a separate process, meaning that each one is in its own sandbox. There's a lot of safety in that - don't feel obligated to condense the number of .t files you have.