[perl #40596] [CAGE] modify perl coding standard test format

[Jerry Gay]

# New Ticket Created by Jerry Gay
# Please include the string: [perl #40596]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40596 >

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

[Chris Dolan]

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?

Chris

[Jerry Gay]

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

[Chris Dolan]

On Oct 25, 2006, at 3:23 PM, jerry gay wrote:

> 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

Jerry:
* open t/codingstd/perlcritic.t
* search for "-format"
* look at the below URL for the allowed sprintf-like codes
http://search.cpan.org/~thaljef/Perl-Critic-0.2/lib/Perl/Critic/
Violation.pm#OVERLOADS

The current format is:
-format => '[%p] %m at %l,%c',
which yields
"[TestingAndDebugging::RequireUseStrict] Code before
strictures are enabled at 235,1"

If you want to see fewer errors, add
-top => 5
after the -format to only show the first 5 violations per .pm file.

Chris

--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)