Question

Say I have a unit test that wants to compare two complex for objects for equality. The objects contains many other deeply nested objects. All of the objects’ classes have correctly defined equals() methods.

This isn’t difficult:

@Test
public void objectEquality() {
    Object o1 = ...
    Object o2 = ...

    assertEquals(o1, o2);
}

Trouble is, if the objects are not equal, all you get is a fail, with no indication of which part of the object graph didn’t match. Debugging this can be painful and frustrating.

My current approach is to make sure everything implements toString(), and then compare for equality like this:

    assertEquals(o1.toString(), o2.toString());

This makes it easier to track down test failures, since IDEs like Eclipse have a special visual comparator for displaying string differences in failed tests. Essentially, the object graphs are represented textually, so you can see where the difference is. As long as toString() is well written, it works great.

It’s all a bit clumsy, though. Sometimes you want to design toString() for other purposes, like logging, maybe you only want to render some of the objects fields rather than all of them, or maybe toString() isn’t defined at all, and so on.

I’m looking for ideas for a better way of comparing complex object graphs. Any thoughts?

Answer 1

What you could do is render each object to XML using XStream, and then use XMLUnit to perform a comparison on the XML. If they differ, then you’ll get the contextual information (in the form of an XPath, IIRC) telling you where the objects differ.

e.g. from the XMLUnit doc:

Comparing test xml to control xml [different] 
Expected element tag name 'uuid' but was 'localId' - 
comparing <uuid...> at /msg[1]/uuid[1] to <localId...> at /msg[1]/localId[1]

Note the XPath indicating the location of the differing elements.

Probably not fast, but that may not be an issue for unit tests.