Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

junit test and object serialization

 
Ravi Danum
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hello,

I am writing a JUnit test. 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.


Thanks for any help that you can give.

Ravi

 
Rob Spoor
Sheriff
Pie
Posts: 20495
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's move this to our testing forum.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34084
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ravi,
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?
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic