Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #40593] [CAGE] make t/codingstd/linelength.t output look like other coding standard tests

3 views
Skip to first unread message

Jerry Gay

unread,
Oct 24, 2006, 5:32:55 PM10/24/06
to bugs-bi...@rt.perl.org
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40593]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40593 >


this test differs from other coding standard test in output format:
~ should display filenames for failing files
~ should execute as one test, not many
there may be other differences that a more proper code review will
uncover. this is your ticket to provide that code review :)

~jerry

Will Coleda

unread,
Oct 24, 2006, 5:58:44 PM10/24/06
to perl6-i...@perl.org, bugs-bi...@netlabs.develooper.com
Not all tests follow the "one test reporting on many files" paradigm:
see t/codingstd/perlcritic.t

FWIW,in general, I prefer the perlcritic method.

--
Will "Coke" Coleda
wi...@coleda.com


Jerry Gay

unread,
Oct 25, 2006, 2:25:18 PM10/25/06
to Will Coleda, perl6-i...@perl.org, bugs-bi...@netlabs.develooper.com
On 10/24/06, Will Coleda <wi...@coleda.com> wrote:
> Not all tests follow the "one test reporting on many files" paradigm:
> see t/codingstd/perlcritic.t
>
> FWIW,in general, I prefer the perlcritic method.
>
as i just wrote in a new ticket for perl coding standard test reformatting...

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.

therefore, we're going with one test per standard, rather than one
test per standard per file.
~jerry

0 new messages