Another good reason to ship all of your development tests with code is that it makes it easer for users to submit patches with tests. Or to fork your code and retain all your development tools and methods.
Since most Perl modules go up on CPAN and nowhere else, I think that the CPAN distribution should contain as much of the useful development environment as possible. That includes POD tests, coverage tests, benchmark tests, developer documentation, nonsense poetry, scraps of paper, bits of string. However, personally I think all POD tests and coverage tests should be skipped at install time unless the user specifically asks for those tests to be run. For one thing, they slow down the install and rarely provide useful information to the user. For another, they may generate errors that prevent install, even though the module works correctly. For instance, if my POD extraction tools are slightly different than the developer's POD extraction tools, and this causes a POD coverage test to fail, then the module will fail to install even though it would have worked correctly. Maybe I get all my documentation from search.cpan.org and I don't care whether the module's docs are considered 'kwalitudinous' on my system. Maybe I don't know enough about testing and module development to know that the module still works fine in spite of the failed POD test. Michael ----------------------------------------------------------------------- Michael Graham <[EMAIL PROTECTED]> YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - [EMAIL PROTECTED] -----------------------------------------------------------------------
