many small .t files
I cannot tell you how much I disagree with that.
You're suggesting that it is okay for the module to be a single file, but the tests for that module have to be littered around the file system in lots of tiny files?
So now to test my module, I need a whole support harness to find, run, accumulate and report on those tests, adding layers to what should be the simplest code possible commensurate with getting the task done, and pushing a damn great wedge between the 'edit' and the 'run' in the development cycle.
It takes the greatest benefit of 'interpreted' languages, the removal of the 'compile' step, and throws it away by substituting the 'test' step. And for what benefit?
You now have to sit and wait for it to (re-run) all the tests of all code that you haven't changed, in order to gain a pretty number telling you "XX.X% passed", when what your really want to know is.
Failure at line nn.
And preferably, be dropped back into your editor, with that line highlighted. Running any tests after that failure is pointless, because like the warning issued by Perl when you omit a semicolon or brace, only the first one is real and the others are often as not cascade failures from it.
It makes no sense to me at all.