Sunday, 26. April 2015
Testing Equals Semi-Automated
If you override Object.equals(..) you should also override Object.hashCode(). So your unit test for your class may look like:

    MyClass one = new MyClass();
    MyClass anotherOne = new MyClass();
    assertEquals(one, anotherOne);
    assertEquals(one.hashCode(), another.hashCode();
But does your implementation returns false if the argument is null? Or is a.equals(b) the same as b.equals(a)?

To answer theses questions PatternTesting provides an ObjectTester class which checks that for you:

    MyClass one = new MyClass();
    MyClass anotherOne = new MyClass();
    ObjectTester.assertEquals(one, anotherOne);
But the ObjectTester can do much more for you: it can check all equals implementation of a package hierarchy:

    ObjectTester.assertEqualsOfPackage("java");
For each class in the java package which have overriden the equals method the ObjectTester creates two test objects with the default constructor (if it has one) to verify the implementation.

But stop - what is, if the default constructor creates two different objects which are not equals? E.g. the Date class does it! Then you can exclude classes from the check in different ways:

    ObjectTester.assertEqualsOfPackage("java",
             Pattern.compile("java.*\\.Date"));
Here a Java pattern (which is new in PatternTesting 1.5.1) is used to exclude the Date classes in java.util and java.sql from testing the equals and hashCode implementation.

In a similiar way you can test different properties of your class like Serializable or Comparable with the different XxxTester classes in patterntesting.runtime.junit - try it!

Happy Testing

... comment