Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What I usually recommend people to do, particularly if the test suite gets large, is to name tests after their packages. For SQL::Statement [cpan.org], you would get something like this:

    t/sql/dialects/ansi.t
    t/sql/dialects/anydata.t
    t/sql/dialects/csv.t
    t/sql/eva l.t
    t/sql/parser.t
    t/sql/statement.t
    t/sql/statement/function.t
    t/sql/statem ent/functions.t
    t/sql/statement/getinfo.t
    t/sql/statement/operation.t
    t/sql/s tatement/placeholder.t
    t/sql/statement/ram.t
    t/sql/statement/term.t
    t/sql/sta tement/termfactory.t
    t/sql/statement/util.t

    If you want something more detailed because your packages are too large you can break down those final .t tests into finer-grained tests.

    t/sql/statement/function-equal.t
    t/sql/statement/function-noequal.t
    t/sql/stat ement/function-lower.t

    By switching to this system, it makes it ridiculously easy to figure out where every test goes (not true for many large test suites) and it also makes it easy to write editor tools to jump between tests and packages.

    And cross-post this to blogs.perl.org [perl.org]! It's gotten to be fairly stable and more people are switching :)