Alot of the modules in the core have (or had) double lives on CPAN.
Alot of the tests are enormous. And t/ is, in general, something of a
mess.
Part of the problem is its fairly flat directory structure. t/ is
broken up into only a few subdirectories:
base, cmd, comp, io, lib, op, pod, pragma.
t/lib is my current target. Currently, each module has a single test
file in lib/ (if it has one at all). This is in sharp contrast to
your usual CPAN module, which often has several test scripts in t/.
This both makes it difficult to make the transition from CPAN module
to core module, and encourages monolithic (and difficult to maintain)
test programs. Expanding t/ will also make it a bit more obvious when
a library is uncovered. It also gives tests a nice place to stick
temp and support files. Finally, a consistent structure will make it
easier to introduce embedded tests (oh, did I mention that idea? See
Pod::Tests).
t/lib/ should look something lib/. Instead of 't/lib/ansicolor.t' it
should be 't/lib/Term-ANSIColor.t' or perhaps
't/lib/Term/ANSIColor.t'. For a module with multiple test files, it
would be (Test.pm as the example):
t/lib/Test/fail.t
t/lib/Test/mix.t
t/lib/Test/onfail.t
t/lib/Test/qr.t
etc...
Tests which don't fit nicely into these slots (such as 1_compile.t)
will remain in t/lib/
Fortunately, this is a fairly rote process. Unfortunately, its not
easily automatable since the current test naming scheme is
inconsistant. Also, some tests rely on their name being what it is.
No worries, though, this can be done as an incremental process.
Thought... we might want to add a "so, you're not a C programmer?"
section to perlhack mentioning jobs like this for those who want to
get involved but not yet ready to hack core.
Anyone see anything horribly wrong with this?
