Automagic unit tests for upholding Object method contracts in Java?

Question

When developing Java applications, I often override Object methods (usually equals and hashCode). I would like some way to systematically check that I\'m adhering to the co

Answer 1

    public static void checkObjectIdentity(Object a1, Object a2, Object b1) {
        assertEquals(a1, a2);
        assertEquals(a2, a1);
        assertNotSame(a1, a2);
        assertEquals(a1.hashCode(), a2.hashCode());
        assertFalse(a1.equals(b1));
        assertFalse(a2.equals(b1));
        assertFalse(b1.equals(a1));
        assertFalse(b1.equals(a2));
    }

Usage:

        checkObjectIdentity(new Integer(3), new Integer(3), new Integer(4));

Can't think of anything better. Add new calls to checkObjectIdentity when you find a bug.

Answer 2

Maybe I'm misunderstanding the question (and being too CS), but it doesn't sound like the problem you're describing is decidable in the general case.

In other words, the only way a unit test can assure you that an overriding method works the same on all inputs as the overridden method would be to try it on all the inputs; in the case of equals, that would mean all object states.

I am not sure if any current test framework will automatically trim down and abstract the possibilities for you.

Answer 3

Just a some initial thoughts on that question (which may explain why there are still no answer after a full hour!? ;)

There seems to be two parts when it comes to implement a solution to the question:

1/ retrieve every classes of my own. Easy, you give a jar name, the Junit test initialization method would:

• check if that jar is in the JUnit execution classpath
• read and load every classes in it
• memorizes only those for which equals() and hash() has been declared and redefined (through Reflection)

2/ test every objects
... and therein lies the catch: you have to instantiate those objects, that is create two instances, and use them for equals() tests.

That means if your constructors are taken arguments, you have to consider,

• for primitive types arguments (int, boolean, float, ...) or String, every combinations of limit values (for a String, "xxx", "", null; fonr int, 0, -x, +x, -Integer.MIN, +Integer.MAX, ... and so on)
• for non-primitive types, build an instance of those to be passed to the constructor of the object to test (meaning you recursively have to consider the constructor parameters of that parameter: primitive types or not)

Finally, not every parameters automatically created for those constructor would make sense in a functional way, meaning some of those values will fail to build the instance because of an Assert: that must be detected.

Yet it seems to be possible (you can make it a code-challenge if you want), but I want first let other StackOverflow readers respond to this issue, as they may see a far simpler solution that I am.

---

To avoid combinations problem and to keep test relevant testing values close to the actual code itself, I would recommend the definition of an dedicated annotation, with a String representing valid values for constructors. There would be located right above the equals() overridden method of one of your object.

Those annotation values would then be read, and the instances created from those would be combined for testing equals(). That would keep the number of combinations down enough

Side-node: a generic JUnit test case would of course check that, for each equals() to tests, there is:

• some annotations as described above (unless there is only default constructor available)
• a corresponding hash() method also overridden (if not, if would throw an assert exception and fail on that class)

Answer 4

I think VonC's on the right track, but I would even settle for something less sophisticated, such as a parameterized test that takes in the .class object (for which the Object methods are being tested), followed by a variable number of constructor args. Then, you'd have to use reflection to find the constructor that matches the types for the passed-in arguments, and call the constructor. This test would assume that the parameters being passed into it would create a valid instance of the object.

The downside to this solution is that you have to "register" each class you want to test with this test class, and you have to make sure that valid input is given to the constructor, which would not always be easy. In that light, I'm on the fence as to whether or not this would be more or less work than manually writing all the tests for each class anyway.

Vote up if you think this could work...leave a comment if you want me to flush it out more (if it turns out to be a feasible solution, I may just do this anyway)

Answer 5

[community post here, no karma involved ;) ]

Here is another code-challenge for you:

One java class, implementing a JUnit test case, with a main method able to launch JUnit on itself!

This class will also:

• override hash() and equals()
• define a few attributes (with primitive types)
• define a default constructor but also some constructors with various combinations of parameters
• define an annotation able to enumerate "interesting" values to pass to those constructor
• annotate equals() with those "interesting" values

The test method takes a class name parameter (here: it will be itself), check if the class with that name has an equals() overridden method with "interesting values" annotations.
If it does, it will builds the appropriate instances (of itself) based on the annotations, and test equals()

This is a self-contained test class, which defines a mechanism able to be generalized to any class with an annotated overridden equals() function.

Please Use JDK6 and JUnit4.4

That class should be copied-paste in the appropriate package of an empty java project... and just run ;)

---

To add some more thought, in response to Nicolas (see comments):

• yes the data needed for test are within the class candidate to be tested (that is, the one overriding equals and helping any 'automatic tester' to build appropriate instances)
• I do not see that exactly as "testing logic", but as useful comments on what is supposed to do the equals (and incidentally as data to be exploited by the aforementioned tester ;) )

Should annotations representing potential testing data never ever be in the class itself ?... Hey that could be a great question to ask :)

Answer 6

This problem doesn't have "easy" solution unless you're putting strong constraints on your classes.

For example, if you're using several constructors for a given class, how can you ensure that all your parameters are well taken into account in your equals/hash methods? How about defaults values? These are things that, unfortunately, cannot be automated blindly.