On Thu, Feb 02, 2006 at 10:01:48AM -0800, Tyler MacDonald wrote: I strongly feel that authors should keep everything necessary for their distribution public; either in the CPAN distribution itself, or via a "permanent" publicly available version control system.
Who's to say you won't lose interest in maintaining the module or in perl altogether at some point? Or move to Antarctica and be unable to maintain it? Or have your home/business or wherever your files are kept destroyed in a hurricane or other natural disaster? And, of course, we all will die someday. Some suddenly. I do agree that many (all?) of these tests are irrelevant to someone packaging your distribution. > Chris Dolan <[EMAIL PROTECTED]> wrote: > > * copyright.t - Ensures that there is a "Copyright ".([localtime]-> > > [5]+1900) somewhere in every .pm file. Will break 11 months from now. > > * distribution.t - Relies on Test::Distribution, which is not in my > > prereq list > > * perlcritic.t - Runs Test::Perl::Critic on all .pm files. Will > > fail without my specific $HOME/.perlcriticrc "Test::Perl::Critic allows you to configure Perl::Critic by passing the path to a F<perlcriticrc> file in the C<use> pragma. For example: use Test::Perl::Critic (-profile => 't/perlcriticrc'); all_critic_ok();" Probably you'd like this to keep in sync with any changes to your .perlcriticrc, which may require some changes to your Makefile.PL/ Build.PL. > > and will fail with future, more exhaustive versions of P::C It would be nice if there was some way to indicate which version of P::C was expected to pass, and TODO any newly looked for problems. > > * spelling.t - Runs Test::Spelling. Will fail without my custom > > dictionary There's Test::Spelling::add_stopwords and =for stopwords. These should be used as much as possible instead of adding to your custom dictionary. But at least your custom dictionary is recreatable (because all the needed words are included in your pod :) should someone else pick up maintenance of your distribution. > > * versionsync.t - Checks that the $VERSION is the same in all bin/* > > and *.pm files. This test is pointless after release, since it's > > already been tested before release > > * pod.t - Checks POD validity. This test is pointless after > > release, since it's already been tested before release > > * pod-coverage.t - Checks POD completeness. This test is pointless > > after release, since it's already been tested before release > > > > and one I have not yet employed: > > * coverage.t - Ensures that Devel::Cover totals are higher than > > some threshold > > Wow, you really *are* exhaustive. How do you find the time to write any > code? ;-) > > Now that I understand exactly what you mean by "author" tests, here's what I > think: Whatever convention you're using, if these tests are only going to > work on your system, then they definately shouldn't be in "t". And since > there's absolutely no value in these types of tests for anybody else except > the module author, there's no real point in having a convention, just stick > 'em anywhere that the make/buildfiles will ignore them. I disagree; presumably anyone running disttest would want these tests run, so they belong in t and named .t, with an appropriate skip_all at the top. Does anyone have a problem with disttest setting PERL_TEST_EXHAUSTIVE? Or a suggestion for a better name? Chris, how are you currently set up to run these tests only when preparing a release?
