Tyler MacDonald writes: > Chris Dolan <[EMAIL PROTECTED]> wrote: > > [lots of author test examples, including:] > > > * 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-coverage.t - Checks POD completeness. This test is pointless > > after release, since it's already been tested before release > > ... 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.
That premise is untrue. Some module authors sync the version numbers of all files (like Chris apparently does); some prefer only to bump the version number in a file if that particular file has changed. If I'm sending a patch to a module author I sometimes try to make it be a complete patch for the distro -- including the code, the docs, updating the change-log, and so on. And hopefully I'd run the tests before submitting the patch. So the inclusion of versionsync.t would clue me in that Chris wanted all the version numbers changing, and I could do that in the patch, thereby reducing the work Chris has to do to accept my patch and increasing the chance of me getting the feature I wanted included. Or perhaps as a user of a module I think the docs could do with a little improvement. Before submitting a patch it'd be useful to run pod-coverage.t to check that I haven't missed anything or made matters worse. Remember that this is software with the source available -- so there isn't a strict author v user distinction: any user can suddenly elect to modify the code and become an author (even if only for modifying a private version). Smylers
