in reply to Skipping tests if a module is not available

This is canonical:
eval "use Test::Pod 1.14"; plan skip_all => "Test::Pod 1.14 required for testing POD" if $@;

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^2: Skipping tests if a module is not available
by Jeffrey Kegler (Hermit) on Oct 31, 2007 at 04:21 UTC
    It's not only canonical, it works! Thanks.

    I am curious what "canonical" means. Is it roughly equivalent to "used in lots and lots of well-written modules"?

    And what is the best way of searching/browsing modules? Before troubling my fellow monks with this inquiry, I tried to find test scripts that tackled this same issue, and was perplexed not to be able to find any. I suspect it was the quality of my search rather than lack of relevant scripts to be found.

      This is one of those things that you wouldn't have known if you haven't written a module for CPAN. In many CPAN distros, you'll find a pod.t and (possibly) a pod_coverage.t. Those use Test::POD and Test::Pod::Coverage respectively. In the POD for those test tools, you'll see this form. But, unless you write for CPAN where your POD syntax and coverage are important, it's unlikely you'll have ever run into those modules.

      I'd estimate that 90% of the usage that I gave you is to test for Test::POD or Test::Pod::Coverage. The rest tends to be for Test::Memory::Cycle and Test::Weaken and the like. For things like Test::Warn or Test::Deep, those are just made build requirements.


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

        I think Canon is more appropriate for this sense.