Trac'ing tests status

[Allison Randal]

Moritz Lenz wrote:
> Allison Randal wrote:
>> Will Coleda wrote:
>>> We should be following rakudo's example of not closing tickets for
>>> which tests could be written.
>> I'd rather see a new ticket created for adding the tests,
> 
> And who creates that ticket?

The same person who would have reviewed the ticket and decided not to 
close it because it needed tests added.

So you know where I'm coming from, we still have 2-5 year old tickets 
open in RT that are practically un-closable, because they have no clear 
task to complete (far fewer than before, though, thanks to the efforts 
of several people). Keeping the purpose of each ticket clear and simple 
helps avoid that.

> Somehow this sounds to me like more work than necessary; but then again
> I mostly write tests for Perl 6 stuff, which is often easy: the bug
> reports mostly contain a piece of code that misbehaves, turning that
> into a test is no rocket science.

That is pretty straightforward. We get some of those, a bug report with 
a minimal PIR example to show the problem.

> So I see two possibilities: either the parrot bugs are much harder to
> test for - than the idea of giving them to newbies is moot. Or they are
> simple to test with some code snippet already provided - then it's easy
> to turn that into a formal test, no need to encapsulate it into a
> separate ticket.
> 
> Is there enough middle ground between those two possibilities to warrant
> the extra work flow effort?

I'd give the developer a choice "either commit the test with the fix, or 
create a separate ticket for the test". They can decide which is more work.

Allison