On 10/25/06, Chris Dolan <[EMAIL PROTECTED]> wrote:
On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote:

> modify perl coding standard test format to match the c tests--one test
> per standard, rather than one test per file.
>
> coding standard tests are designed to test maintainability, not
> functionality. testing parrot functionality is much more important
> than testing maintainability--just look at perl 5 :-)
>
> inflating test numbers (and percentages) by adding a zillion coding
> standards tests leads to false perception of test coverage. i'd like
> very much to avoid this situation.
> ~jerry

Jerry,

I fully understand your reasoning, but this is going to slow down the
tests.  Perl::Critic's overhead comes primarily from parsing each
source file, not from checking the standards, so Test::Perl::Critic
is oriented to work per-file.  Your suggested change goes across the
grain for Perl::Critic.

Certainly the perlcritic.t can be changed to have just one test --
all files pass all standards, or not -- without a performance
penalty, but perhaps that might be too much in the other direction?

one overall test for perlcritic is fine with me. there's nothing
stopping us from parsing perlcritic output if we want a different
format, however i'd rather not go that far.

additionally, i'd like to see less verbose output from perlcritic. the
thousands of lines of diag output from a single test file is
...distracting. i'm sure it's configurable, but i haven't taken the
time to look into it. do you have any quick suggestions, or should i
dive into the docs?
~jerry

Reply via email to