in reply to Perl tools for making code better
G'day Leitz,
That's a great list from ++Tux. I also use the core module, ExtUtils::Manifest; typically like this:
#!perl use strict; use warnings; use Test::More; BEGIN { if (! $ENV{RELEASE_TESTING}) { plan skip_all => 'Author test: $ENV{RELEASE_TESTING} false.'; } } use ExtUtils::Manifest qw{manicheck filecheck}; plan tests => 2; is_deeply([manicheck()], [], 'Check files in "MANIFEST" exist.'); is_deeply([filecheck()], [], 'Check for files not in "MANIFEST" or "MA +NIFEST.SKIP".');
I typically create modules using Module::Starter via module-starter with Module::Starter::PBP as a plugin.
"For example, using a Perl::Critic plug-in while developing code is fine, shipping those add-ons is something I would avoid."
If you're using, for example, Test::Perl::Critic for development but you're not shipping it, you will have to remove the test from your t/ directory and modify your MANIFEST file prior to running "make dist". You will need to do this for possibly quite a few similar tests. This would be tedious as well as being error-prone (easy to get the two versions out of sync). Consider using "... skip_all => 'Author test ..." as I showed in the code above.
There was some recent discussion about naming conventions for test files. You can see how I normally number these. For "Author tests", I have recently been adding 99- to the start of those (which I find makes it clear what they are). A listing of my t/ directory would typically include files like:
99-00_pod.t 99-01_pod_coverage.t 99-02_manifest.t
Do note that is what I choose to do. Others have their own conventions. Do not feel in any way compelled to follow what I do.
— Ken
|
---|