I am writing a JUnittest. The objects I am testing contain many other objects. Some of these objects are Maps and Lists that contain other objects.
I want the JUnit tests to test for equality of the objects.
As I see it, there are four ways to go about this:
1) serialize the objects and then compare the byte arrays.
2) call an equals method in the object itself; however, the objecst to be tested have already been written, so I don't think I will be able to add an equals method to the objects.
3) have the JUnit tests perform the equals test themselves by testing each element of the map or list. This would require that the JUnit test knows each of the objects very well, instead of letting this knowledge stay in the object.
4) create a helper object that handles equals for various kinds of objects -- not the best design because this class could grow without bounds as more objects are added.
I wouldn't go with option #1 because it would be very difficult to figure out why the assertion was failing. I also wouldn't go with #2 because that requires writing both the equals and hashCode methods correctly and then testing them.
Option #3 is an option. I would go with option #5 though. Which is to add a toString() method to the object. It's easier to write toString() correctly than equals. It's also easier to see why the objects are different because junit highlights the differences in the string. If you can't update the class at all, you could write the toString elsewhere. But that's awkward. Why can't you change the code? Does another team/company own it or is just phobia of changing "already written" code?