I have to say that "whatever you feel comfortable with" isn't
really an adequate answer to this kind of question: yeah there's
lots of ways that things can be done, but some are more common
that others, and other things being equal, it's going to be
better to go with "standard practice" rather than making up a new
way of doing things.
That said, Old_Gray_Bear's version of "standard practice" doesn't
sound bad, and might not be a lot different from what I do,
which is:
-
Scatter "t" subdirectories throughout the code tree, with tests
located near the code that they test. So the tests for
Modular/Stuff.pm are in Modular/t.
-
When first writing tests for Modular::Stuff, I name the test file
Modular-Stuff.t. As the tests get more elaborate, I move the
tests into numbered files (e.g. 00-init-Modular-Stuff.t,
01-db_access-Modular-Stuff.t, 02-data_munging-Modular-Stuff.t...).
-
I put data files that tests use in a sub-directory of t called "dat",
and I sometimes put shared code for these tests in modules
located in a sub-directory called "lib".
And yes, prove -r is indeed the way to run it recursively.
It really is a good ideas to get familar with prove, starting
with the man page.
One of the nice things about "prove" by the way, is that you can
narrow down the tests that you run with it by doing things like:
prove '0*.t' '1*.t'
Lately I've been playing around with reserving blocks of numbers
for tests-under-development that aren't expected to work yet.
Tests named '0*.t' or '1*.t' had better work, or something has
come unstuck, but a failure in tests named '2*.t' of '3*.t' just
means you haven't finished something yet.