[perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
Will Coleda via RT
parrotbug-followup at parrotcode.org
Wed Feb 25 17:40:09 UTC 2009
On Thu Nov 20 04:16:53 2008, jkeen at verizon.net wrote:
> On Wed Nov 19 23:13:27 2008, mark at glines.org wrote:
> > James Keenan via RT wrote:
> > > On Tue Nov 18 10:22:25 2008, mark at glines.org wrote:
> > >
> > > This will probably be quite challenging. Let's assume that all
tests
> > > are found in files with names ending in '.t'. Those .t files can
be
> > > written in any language, which probably have different ways of
> > > classifying a test as TODO.
> > >
> > > My count tonight is that 1384 .t files in the distribution. Of
these
> > > 524 are *not* found under ./languages/.
> > >
> > > I wonder if we could formulate the specification in this ticket a
bit
> > > more precisely before someone embarks on coding.
> >
> > Yes, absolutely. I just added the basic ticket on the spur of the
> > moment, to make sure I didn't forget about it.
> >
> > I've been thinking about this. A few things come to mind, for
instance
> > detecting the language based on the hashbang (if any) or
subdirectory
> > it's in, and invoking a language-specific parser. And detecting the
> > cases we can't handle, and skipping those.
> >
> > But to me that sounds like way too much work. It doesn't really
matter
> > to me whether the ticket number occurs within the TODO output
string, a
> > nearby comment is good enough for me. So how about skipping all the
> > above nonsense and just ignoring the test language entirely? How
about
> > a simple regex-based test that tallies all instances of /TODO/ in
the
> > set of test files, skipping the lines that start with obvious
comment
> > characters, and for each instance, looks for a match of /#\d+/? It
can
> > even expand the search to also look a couple lines above and below
the
> > TODO line, for additional flexibility. I think that should be
> > reasonable for most, if not all, possible test languages.
> >
> > Do you think that would catch all the cases?
>
>
> Two thoughts:
>
> 1. We already have code that can detect the existence of TODO in
> certain kinds of files. Cf. t/codingstd/fixme.t. Paul Cochrane used
> that a couple of years back to generate hundreds of RTs -- most of
which
> are probably still outstanding. Can we leverage that
> Parrot::Distribution-based code?
If we're really going to enforce this, we should write a TAP parser that
verifies that any TODO/SKIP messages refer to a ticket. But don't do
that.
I think it's overkill to work on this, and would much rather see time
spent un-TODO-ing and un-SKIP-ping tests. In fact, in the time it takes
for us to figure out a programmatic way to do this, we could probably
just do it by hand.
-1
--
Will "Coke" Coleda
More information about the parrot-dev
mailing list