Running tests on the target machine allows to discover portability problems and bugs that didn't show on the module author environment. But pods are just documentation, they are not affected by the environment, if they were right on his computer when he tested them before packing the module, they are going to be the same on the target system, so why bother testing them and actually introducing new code that, as in your case, can contain new bugs? it is just counterproductive!

A good aproach could be to skip pod tests unless they are explicitely requested by the user installing them, for instace defining some enviroment var (TEST_PODS) or looking for some dummy file on the file system.

A better approach would be to make their execution depend on the action, so someone saying ./Build disttest would get them, whereas someone saying ./Build test would not.

Makeshifts last the longest.

Great idea! Here's a quick and dirty implementation:

package Module::Build::SillyPodTests;

use SUPER;
use base 'Module::Build';

use Module::Build;

sub ACTION_disttest
{
    my $self = shift;
    local $ENV{PERL_TESTPOD} = 1;
    super();
}

sub find_test_files
{
    my $self  = shift;
    my $tests = super();

    return $tests if $ENV{PERL_TESTPOD};
    return [ grep { $_ !~ /\bpod.*\.t\z/ } @$tests ];
}

1;
[download]

Use this in place of Module::Build in your Build.PL file and the only suck is that you still have to distribute the why-make-users-run-them POD testing files.

Edited somewhat.

Well, what's the point in having your module pods (not just coverage) tested on every machine where it is installed?

I agree 100%. My problem was caused by a module that I listed as a dependency. It's very annoying. Someone can't install my module because a module that I have as a prereq fails to pass a coverage test -- falsely -- because of an outdated Pod::Coverage on the tester's machine.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

what's the point in having your module pods (not just coverage) tested on every machine where it is installed?

Some tests are not there just to ensure that things are working, but rather to ensure the user that the author did take his time to do things properly.

I, for one, enjoy seeing that the author took the time to make sure he was documenting every single function in his code.

I could accidentally distribute in a .svn/ directory to "prove" that I use source control too, but it wouldn't do you much good. (Actually I couldn't; I use svk.)

Some tests are not there just to ensure that things are working, but rather to ensure the user that the author did take his time to do things properly.

Running a test doesn't say anything more than that the author managed to write code that produced output in the form:

    print 1..3
    ok 1
    ok 2
    ok 3
[download]

If you want to know the author did things properly, you'd run your tests, not the authors.

I, for one, enjoy seeing that the author took the time to make sure he was documenting every single function in his code.

I'd rather see a manual page that documents the API. Not every function belongs to the API - the more complex a functionality is that a module delivers, the lower the ratio of API functions vs total number of functions will be. Documenting functions belongs in source code comments. POD is user documentation.
Perl --((8:>*

Actually, for those of us who support 'deep' backwards compatibility for their modules, Test::More itself is problematic. If you blindly 'use' it, you can break 5.005 compatibility for people running very old installations that lack Test::More.

Since I wasn't specifically aware of the 'misversioned dependancy' problem with Test::Pod::Coverage, I have not yet written defensive code for it. I have written defensive code for Test::More (example taken from my Class::NamedParms module):

use strict;

use lib  ('./blib','../blib', './lib', '../lib');

eval {
    require Test::More;
};
if ($@) {
    $|++;
    print "1..0 # Skipped: Test::More required for testing POD coverag
+e\n";
    exit;
}
eval {
    require Test::Pod::Coverage;
};
if ($@ or (not defined $Test::Pod::Coverage::VERSION) or ($Test::Pod::
+Coverage::VERSION < 1.06)) {
    Test::More::plan (skip_all => "Test::Pod::Coverage 1.06 required f
+or testing POD coverage");
    exit;
}

Test::More::plan (tests => 1);
Test::Pod::Coverage::pod_coverage_ok( 'Class::NamedParms', { also_priv
+ate => ['DEBUG'] });
[download]

Surely the solution is to mark Test::More as a dependency in your installer. It only became a core module in Perl 5.8.0, though it's also core in Perl 5.6.2 now.

If only life were that simple. Automatic installation of dependancies didn't get added to CPAN until early in 1999. 5.005 came out in mid-1998. Therefore, although modern CPAN can automatically install dependancies, old perl installs don't necessarily take advantage of it because their installed versions of CPAN may be too old.