SWE 637 In Class Exercise Number 2


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.