This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Change rules for adding/changing test cases
- From: DJ Delorie <dj at redhat dot com>
- To: Richard dot Earnshaw at arm dot com
- Cc: rth at redhat dot com, Richard dot Earnshaw at arm dot com, dewar at gnat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 21 Mar 2002 10:24:45 -0500
- Subject: Re: RFC: Change rules for adding/changing test cases
- References: <200203211121.LAA22747@cam-mail2.cambridge.arm.com>
To me, it looks like this:
Patches, changelogs, and PRs tell you this: That it's broken, how to
reproduce it, what it looks like when it's broken, and what the patch
was that fixed it.
The key missing detail is *why* it was broken - the core issue that
caused the bug, and the reason behind why the fix actually fixes it.
This type of hint to the next developer just doesn't exist in anything
today, and *that* is what I think should go in the testcase.
Something like "if this testcase fails, one thing to look at is foo,
because sometimes bar causes grill."
Just little handy notes to the next bug fixer to try to cut down on
debug time.