Michael G Schwern wrote:
Long threads scare me and, I'm sure, other people. Can people sum up what
useful things have been said in that long thread? Skimming it so far it seems
to be:
* POD tests should be run by the user.
* POD tests should not be run by the user.
Anything productive come out of it?
No.
<rant>
In fact, this argument is ludicrus, and here's why:
1. We're playing the Open Source Development game here, of which the prime
directive is "Many Eyes Make All Bugs Shallow". By denying end-users to partake
in this game (by not giving them hints of something wrong) we're not only
denying them a chance to inform themselves of the state of the software they're
about to use, but we're also missing out on feedback that may lead to the
improvement of the software, dependencies, distribution system, distribution
format, tests, documentation or ANY other thing which may be the source of a
failed test.
2. We need to keep ALL the following "users" happy:
- "This is MY module"-developers
- "I'd like to improve this module somehow"-developers
- "I have free time and like to see if this works"-developers
- "I've agreed to test this for CPANTS"-developers
- "I need to make a RPM/DEB package for distribution"-developers
- "I just need this for my job, please don't bother me"-developers
- "I just want to install this, and don't know Perl"-sysadmins
So this shouldn't be a "To test POD or not to test POD" question. This should
rather be a question of what the Best Practices for CPAN module authoring are,
and how we should share these with everyone.
</rant>
Perhaps the arguments should just be summarized on the wiki.
http://perl-qa.hexten.net/wiki/index.php/Testing_POD
I'd rather see a "Best Practices for testing" wiki page, followed up by
arguments, and reflected by the tests and modules produces by skeleton
module-generating tools like Module::Starter, ExtUtils::ModuleMaker.
http://perl-qa.hexten.net/wiki/index.php/Best_Practices_for_Testing
- Salve
