[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-debug-dev] How to verify a bug fix
|
There are two things that should be done when verifying a bug:
(1) Ensure that the function works as expected (this is most important).
(2) Review associated code.
When testing function, also look for usability/performance issues (if
applicable).
Obviously, you need some indication of what code was changed to do #2
(this may or may not be mentioned in the bug report). Ideally, as bug
fixers, we should describe the fix and associated code that was effected
(package or classes, depending on the extent of the fix). Code reviewing
is a world in itself, but you should sanity check high risk areas in the
code. As well, look for updated/complete javadoc in API classes.
Sometimes, looking at the code will reveal obvious flaws in a fix. If you
think the code could be improved/made more readable, etc., you should
improve it, or have the fixer improve it.
Whenever possible, a test (or tests) should be added to the test suite for
the associated function. Ideally, the bug fixer will have done this, and
you can run the test as well.
Darin
Chris Tilt <chris@xxxxxxxxx>
Sent by: jdt-debug-dev-admin@xxxxxxxxxxx
01/08/2004 03:07 PM
Please respond to jdt-debug-dev
To: jdt-debug-dev@xxxxxxxxxxx
cc:
Subject: [jdt-debug-dev] How to verify a bug fix
Hi.
I basic question, but first time again. What is the usual procedure to
verify a bug fix? Usually, the bug fix comments are not going to include
what projects changed, so there must be a good way to see that easily.
Are there assumptions about which build it was compiled against? Is the
HEAD stream consulted for the new source; what assumptions are made
about the scope of the change and the required environment?
Thanks, Chris
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev