Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

junit test and object serialization  RSS feed

 
Ravi Danum
Ranch Hand
Posts: 154
1
  • 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
Posts: 21047
85
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: 37180
515
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?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!