# from Gabor Szabo
# on Tuesday 10 June 2008 18:03:
>With that said I have no idea how could CPANTS check that you lived up
>your promise
>and ran both
>
>`./Build testpod`
>`./Build testpodcoverage`
>
>with success, prior to release.
First, I already stated:
"While it *might* indicate that I tested the pod/podcoverage, it
doesn't actually say that I did."
So, you're already "taking my word for it", but currently asking that
said promise be rather lengthy and cumbersome to maintain.
A better way? Testing the pod validity is pretty straightforward.
Isn't there a metric that does that in Module::CPANTS::Kwalitee::Pod?
If so, what is the use of the has_test_pod metric?
Testing the pod coverage is a bit trickier, as David pointed out WRT
putting your pod $over_there, and if you'll recall the easter herring,
there's that issue about the glob assignments and that you have to load
the code for Test::PodCoverage to work -- so we've got a cross-platform
issue too where the win32-only modules can't be checked on linux and
vice-versa in addition to the discussion about whether or not
documentation is required for accessors/mutators/aliases/subclasses.
Thus: what we have now is an unreliable and overly verbose way for me
to say "trust me." I suggest either or both of:
1. A static scanning tool.
2. A more efficient form of $take_my_word_for_it = "true"
Or even a variable (e.g. in META.yml (or not)) which states which tool
is used for the coverage. Then, given a selection of one-or-more
static (and/or "runs the code") podcoverage checkers, the author can
say which one was used and a tester can choose to verify that
(presumably: using a whitelist of static checkers and/or being
adventurous enough to whitelist something like Test::PodCoverage.)
--Eric
--
"Time flies like an arrow, but fruit flies like a banana."
--Groucho Marx
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
