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
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
You're kidding, right? (Score:1)
I don't have any sympathy for the "uses_test_nowarnings" metric (mainly because it promotes Test::NoWarnings to a universal best practice to be used -- and abused -- everywhere). That happened before with Test::Pod and Test::PodCoverage and their corresponding metrics. On the other hand, to make sure that your code is free from warnings you don't know about is a good idea. But there's code that needs it and others that don't -- just like it happens with "use warnings" or "use strict".
But you're certainly kidding when you said:
Prerequisites (including the one needed for tests, or more generally build) are declared via Makefile.PL/Build.PL with a large array of options to make them optional, recommended, real requirements. The test code may also test for availability of a module and skip the test, like the POD and POD-coverage tests usually do. Adding a fully-fledged CPAN module to t/ to flee from yet another requirement is really a poor alternative. Something better could be done with Module::Install and other similar developer-helper modules (which at least will let you update the embedded dependency at a later date without much suffering).
Reply to This
Re: (Score:1)
Refusing to add unnecessary complexity which only serves to toggle one bit in a Kwalitee index is a sure sign of Actual Quality. This is one case where Kwalitee is very much at odds with Quality.