in reply to Does something like Pod::Coverage::Moose exist for Moo?

Playing around with Pod::Coverage::Moose's test suite, it appears to "just work" for Moo roles. Moo is after all, designed to offer Moose-compatible classes and roles.

Of course, Pod::Coverage::Moose has a dependency on Moose, and perhaps the whole reason you are using Moo is to avoid your project having a dependency on Moose. But in this case it shouldn't be a problem - include the pod coverage tests in the author test suite, but not in the test suite run by people installing your module.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
  • Comment on Re: Does something like Pod::Coverage::Moose exist for Moo?

Replies are listed 'Best First'.
Re^2: Does something like Pod::Coverage::Moose exist for Moo?
by jds17 (Pilgrim) on Oct 24, 2012 at 22:02 UTC

    Thank you for replying again, tobyink. The reason I am using Moo(::Role) is that I want to ensure at compile time that certain classes provide a given set of methods. (For each DBMS to be supported, there is one such class handling DBMS specific things.)

    Since I wanted the module to be as portable as possible, I wanted it to have few dependencies, so Moo won against Moose.

    You are right, pod coverage is mainly of interest to the author(s) of a module, so I could leave the pod coverage tests out for distribution, but I am not completely happy with having two versions of the module.

    Maybe I will take the time and see how Pod::Coverage::Moose works and if I can borrow from there without having to use Moose. But right now I want to get the first version of the module out as soon as possible, there is only some documentation left to be written. For the time being, I think it would be wisest to follow your suggestion and leave the coverage tests out for the users.

      You may have missed my point. You don't need to borrow stuff from Pod::Coverage::Moose, because Pod::Coverage::Moose already seems to support Moo classes and roles.

      Just use Pod::Coverage::Moose as-is, but put the tests in your xt directory instead of t. That way, MakeMaker (or whatever you're using to package your distribution) should find and run the test while it's building the distribution tarball, but the test will not automatically run on end users' systems.

      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

        Oh, I really have missed your point. It's the first time I want to publish a module so this packaging question did not turn up before.

        I will try to use Pod::Coverage::Moose and put the author tests in xt. I found a nice description of handling author tests when using Module::Build here: http://elliotlovesperl.com/2009/11/24/explicitly-running-author-tests. Thank you for putting me on the right track!