These are JUnit exercises. Work in groups.
Consider the equals()
method,
which is defined (and implemented) in the Object
class.
equals()
is often overridden in subclasses
that wish to implement a notion of logical equivalence
between distinct objects.
public class Point { private int x; private int y; public Point(int x, int y) { this.x=x; this.y=y; } @Override public boolean equals(Object o) { // What code goes here? } }
Before we begin, how do we *know* what code is appropriate (or not) for
the equals()
method?
First, let's write the code for equals()
in the Point
class.
What would we do if Point
extended some other class?
Next, let's develop some regular JUnit tests for equals()
.
Next, let's develop some data-driven JUnit tests for equals()
.
Now, let's think more generally.
Develop some theories about the equals()
method.
Implement them as JUnit theories.
Don't worry about Java syntax; worry about what you want to test.
Here's how we'll do the exercise. Spend a few minutes thinking about appropriate theories. As a class, we'll choose one and refine it mathematically. Then each group will go back to trying to implement the theory in JUnit. Lather, rinse, repeat.
Note: This exercise may look trivial, but almost certainly everyone in this classroom (including me!) has written code that violates at least one of the theories we will develop.
If time is available, let's discuss how to extend this
analysis to other common implementations,
such as the Comparable
interface
and its relationship to equals()
,
the relationship between equals()
and hashCode()
,
and the clone()
method.