Nice in theory. Sucks in practice. More than one developer here (on a "must never fail on pain of death" project) has skipped running the entire 1.5 hour test suite because "their one little change" won't break things and their one little test didn't break. When you're in a hurry, one and one half hours can seem like a long time :)

I see your point. We have institued a "must run tests under pain of death before commiting to CVS" policy, but even that can be subverted by modifying the working directory. We have several distinct sub-systems which do not interact with one another (except in maybe in application code that uses the sub-systems), I suppose I could use the prove utility that comes with Test::Harness (my other new favorite toy along with Devel::Cover), to script sub-system tests in some way.

Redundant tests are bad. They slow things down, they are more tests to maintain and they provide no benefit. You don't need to prove that 2+2 == 4 more than once.

Agreed, but what about if they are redundant because they are in a function? Here is an example:

sub test_Base_Interface {
    my ($o) = @_;
    can_ok($o, 'new');
    can_ok($o, 'helloWorld');
}

sub test_DerivedFromBase_Interface {
    my ($o) = @_;
    can_ok($o, 'new');
    can_ok($o, 'gutenTag');

    test_Base_Interface($o);
}
[download]

The can_ok($o, 'new') test is repeated (because 'new' is overridden in 'DerivedFromBase'). Its redundant, but "for a reason" (maybe not a good one). Is this still bad? Or am I being silly and should just use Test::Class or something similar?

-stvn