What's the current approach to turning perlbugs into tests?
In general, the person who fixes the bug writes a regression test for the bug. The pumpkings and other porters are really good about making sure patches have tests.
Should they be done as TODOs? Is there a distinct set of test files for them? etc? Can they use Test::More? etc. etc. etc.
I like the idea and I can see how it would make some things easier. We might get a lot of benefit from a little simpler idea, though.
Putting them as TODO tests might just shift the problem -- too many bugs, not enough people looking at RT to solve them -- into "not enough people are looking at the TODO tests to solve them". Library bugs can use Test::More. Language bugs may or may not, depending on how complex the bug seems to be. (A bug in print would likely need testing in t/op/print.t.)
I could imagine a test case being massaged and mangled a couple of times before it's ready to be checked in. As a matter of policy, if it were up to me, I'd hesitate to go quite that far.
e.g. http://bugs6.perl.org/rt2/Ticket/Display.html?id=5430
can have a fairly simple test like:
package main; eval '::is(__PACKAGE__, "main", "Package is main inside eval")'; package Foo; eval '::is(__PACKAGE__, "Foo", "Package is Foo inside eval")';
But how we actually get that into the core somewhere?
One idea is attaching a simple test case to every bug report that doesn't have test code that's nearly right for the core. It's a lot easier to touch up a test case than it is to write one, so we could do a lot of good by turning bug reports into executable tests without having to worry about where they'll eventually end up.
-- c
