Re: [jdt-debug-dev] How to verify a bug fix

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

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