Adding a kwalitee check for a test that runs Devel::Cover by default might on the surface appear to meet this goal, but I hope people recognize it as a bad idea.
Why, then, is suggesting that people ship tests for POD errors and coverage a good idea?
Although I've now added the automated inclusion of a 99_pod.t to my packaging system (less for kwalitee than that I've noticed the odd bug get through myself) why doesn't kwalitee just check the POD itself, rather than make a check for a check?
Adam K
Because they're two seperate issues.
First, checking the pod syntax is ok for the obvious reasons. Broken pad leads to doc problems.
Second, we're checkling that the AUTHOR is also checking his/her pod syntax and coverage. That's an important distinction.
I would go as for to say that checking the authors development intentions via checks like Test::Pod::Coverage, Test::Strict, Test::Distribution, etc is just as important, if not more, than just checkong syntax and that all tests pass.
Givin two modules with a passing basic.t, I'd go for the one with all of the development side tests over the other. Those tests listed above signal [to me] that the author [probably] pays more loving concern to all facets of their module than the one with just the passing basic.t
-=Chris
smime.p7s
Description: S/MIME Cryptographic Signature
