Stop Pod tests before they stop you!

Have you ever installed a CPAN module with a big dependency chain and had installation fail somewhere in the middle? Have you ever investigated and found the failure was due to Test::Pod or Test::Pod::Coverage?

AAARRRGGGHHH!

I hate that! Pod tests are release tests and shouldn't be inflicted on end users. But some authors got hooked on a crazy fad of bundling those tests. (I blame you, Module::Starter.)

I've figured out a hack to stop those annoying tests: TAP::Harness::Restricted.

It bypasses Pod and Pod coverage tests on the fly. All you need to do is specify it in the HARNESS_SUBCLASS environment variable.

$ cpanm TAP::Harness::Restricted
$ export HARNESS_SUBCLASS=TAP::Harness::Restricted
$ cpanm Thing::With::Lots::Of::Dependencies

Never be bothered by failing Pod tests again!

This entry was posted in hacks, perl programming and tagged , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

7 Comments

  1. Posted March 16, 2013 at 6:07 pm | Permalink

    There ought to be a kwalitee test that checks that any pod tests are skipped when RELEASE_TESTING is not set. (Ditto for spelling, perlcritic, whitespace, and a bunch of other things that are only suitable for author- or release-testing.)

    • Posted March 16, 2013 at 8:46 pm | Permalink

      I'd rather not have those tests in t/ at all, but if they have to be, then RELEASE_TESTING really should be there.

  2. Christian Walde
    Posted March 16, 2013 at 6:51 pm | Permalink

    Can you please add a sentence to the post that informs people of the fact that sending maintainers of such dists RT tickets usually works fine for resolving that kind of issue too? :)

  3. Posted March 16, 2013 at 6:54 pm | Permalink

    As a CPAN user, I share your frustration.

    As the creator of Module::Starter, I make no apologies.

    If you're going to blame anyone, blame the authors who put out modules that fail the tests in the distribution. This is especially true if it's somehow failing a Test::Pod::Coverage test since that's not even machine-specific, as I know that Test::Pod failures can vary depending on many machine-specific factors. Blame the authors who have tests in their distributions and don't ever ask why. Blame the authors who distribute t/boilerplate.t without even knowing what's in it.

    The "crazy fad" you're referring to has been since I put out Module::Starter in 2004. I was trying very hard to get authors to *think* about what they were creating, and to consider the importance of their docs. The CPAN was rife with modules attributed to A. U. Thor created by h2xs.

    • Posted March 16, 2013 at 9:39 pm | Permalink

      I respect your intentions. And the Oslo Consensus that pushed for standardizing on 'RELEASE_TESTING' didn't come out until 2008. I just wish people were more thoughtful about their boilerplate.

      Nevertheless, on big installs, I don't want to suffer for it.

  4. brian d foy
    Posted March 17, 2013 at 1:43 am | Permalink

    I've long wanted a "meh" result instead of "ok" or "not ok". It's a 'not pass' but 'not fail'.

© 2009-2014 David Golden All Rights Reserved