Great question, and great responses so far. I don't have much to add, but I'll throw out some of my preferences.

Depending on the complexity of the modules, sometimes I structure my tests like this:

t/
 - dirA
    |
    - test1
    - test2
 - dirB
    -test1
    -test2
[download]

... like this. This allows me to run an individual directory of tests if I'm just testing a specific area of my code:

prove t/dirA/*.t
[download]

...and in the Makefile.PL within the WriteMakefile() function:

test             => {TESTS => 't/*.t t/*/*.t'},
[download]

Other projects, I just have consecutively numbered test files, where each test file typically only focuses on a specific subroutine or issue: like this.

But mostly, I write tests as I write new subs, and number my test files with gaps in the numbers, eg: 05-load.t, 10-subA.t, 15-subB.t etc. This way, I have gaps in the event I need to add in a new test file at a specific location (between subA.t and subB.t for instance, like this.

My preferred way changes depending on the project, but mostly I opt to have sequential numbers with the gaps in between like my last example above).

To boot, because pretty much all of my code is open source and in Github, I use Travis CI for continuous testing on every push, tied with Coveralls.io, which provides (a basic overview) of the test coverage, also on each commit. Here's an overly verbose .travis.yml configuration file that automates Travis/Coveralls for me.

Then, once I get near or to 100% coverage with Coveralls, I use Devel::Cover as most others do to get fined grained test coverage results, adding tests and/or test files as necessary.