Instructions:
Work with your neighbors in groups.
We'll stop several times throughout the exercise for
groups to present their work.
Here's a traditional maintenance problem:
The implementation of the
Iterator
interface in the Java
collection classes has a corner-case bug in terms of how it generates exceptions.
Specifically, the hasNext()
method
fails to throw ConcurrentModificationException
when this behavior is expected.
For an example of this problem, see the
ArrayList
class.
Here's a
failing JUnit test
(See test 3, testHasNext_C5()
).
-
In what sort of tool should this information be presented to you?
Why is this important?
-
Where is the problem: in the test case or in
ArrayList
?
How do you know? Be as specific as possible.
-
Which of the four types of maintenance (See Offutt's maintenance overview essay)
does this activity represent?
-
What analysis should you do before even starting to think about changing any code?
-
Let's suppose we ignore the conclusion of the previous
step and decide to correct the bug.
Consider each of the five "truths" in Singer's article.
How relevant is each one?
-
Find the code. There are various options.
If your group finishes early, help another group.
-
What do you think of this code from a style perspective?
Consider programming style, comments, understandability, etc.
Is the code of sufficient quality to carry out the assignment?
-
Determine the most logical change to the code to fix the problem.
How did you arrive at your conclusion?
What analysis supports your conclusion?
-
Go ahead and correct the problem. (If you can compile the result in real-time
during the exercise - great! Otherwise, imagine that you can.)
-
What else do you need to do prior to deploying your patch?