• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Trying to get started using JUnit

 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all.

I've been reading about JUnit and the whole Unit Testing concept and, while it has long seemed a good idea, I've been reluctant to get started - mainly because I haven't known where to start.

So, anyway, I'm now trying to get started doing some unit testing and, as I'm already using Eclipse, JUnit seems a great way to go. Unfortunately, as I'm an idiot, I don't especially know what I'm doing. Perhaps you can help me get started.

Here's the situation. I have a method which reads a parses a file and puts the data in that file into a Hashtable. This method is working, but I'd like to do some refactoring without changing the functionality so I thought this would be an excellent place for me to start using JUnit.

I have written the following test class:



I've assembled the Hashtable that I want the method to produce in my setUp method and then I invoke the method I want to test in my testReadDocTypeDef() method.

However, here's where I'm unsure of where to go. How do I test that one Hashtable is the same as the next? If I use assertEquals, as I did here, I get a failure because the equals method, as defined in Hashtable, checks for object equality by checking reference values. Obviously, the two Hashtable objects are distinct objects so this fails even though the two Hashtables contain the same data in the same structure (I verified this through the use of my debugger).

So, how can I verify that my test succeeded? Do I need to pull the various pieces out of my hashtables and verify them?

Also, what should I do about exceptions? As you can see, the method I'm testing can throw a FileNotFoundException or some other IOException. In order to compile this, I need to catch those exceptions. Is there something I should be doing in the event that such an exception is caught? Should I be doing something like this?



This would force a failure if an exception was thrown, but I'm not entirely sure if that's even what I'd want to do.

I'm sure these questions are rudimentary for most of you, but I'm new to this and trying to feel my way through this a little bit. Any advice you can offer is greatly appreciated.

Thanks,
Corey
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Corey McGlone:
How do I test that one Hashtable is the same as the next? If I use assertEquals, as I did here, I get a failure because the equals method, as defined in Hashtable, checks for object equality by checking reference values. Obviously, the two Hashtable objects are distinct objects so this fails even though the two Hashtables contain the same data in the same structure (I verified this through the use of my debugger).



Are you sure about this? I understand the JavaDoc to say that it should work as expected (that is, checking for structural equality). Perhaps you should try HashMap instead of Hashtable?

So, how can I verify that my test succeeded? Do I need to pull the various pieces out of my hashtables and verify them?



That would be another option, which is quite common for custom data structures. You should then probably extract that code into its own, custom assert method (such as assertEquals(Hashtable, Hashtable)).


Also, what should I do about exceptions?



Just add a throws clause to your test method and remove the try-catch block. The JUnit framework will safely catch any exception thrown by your test and flag the test as "error".
 
author
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to the JavaDoc, all implementations of Map compare the entry sets using equals(), and Set does the same with its Map.Entry elements, so equals on a Hashtable should work.

I coded it to test it out, and indeed Hashtable.equals() behaves correctly.



Also, what should I do about exceptions? As you can see, the method I'm testing can throw a FileNotFoundException or some other IOException. In order to compile this, I need to catch those exceptions.



You can throw exceptions up to JUnit, like I did above (my test method throws Exception). JUnit will handle them and report them as failures. Now you should only do this for unexpected exceptions. If you want to test throwing an expected exception correctly, see recipe 2.8.
[ August 10, 2004: Message edited by: J. B. Rainsberger ]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Corey McGlone:
Should I be doing something like this?





Yes, something like that. The "right way" is to call fail(String), which more or less just asserts false. So the code might look like

 
Corey McGlone
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the responses, everyone. As you know, I had originally thought that the equals() method of Hashtable had not been overridden. Obviously, that wasn't correct.

It hit me last night, my Hashtable has a custom data object in it call DocTypeData. I had never overridden the equals() method for this data type so that is where my error was coming from. Because the two DocTypeData objects were distinct, the equals() method had been returning false.

Thanks for the help, folks.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Corey McGlone:
It hit me last night, my Hashtable has a custom data object in it call DocTypeData. I had never overridden the equals() method for this data type so that is where my error was coming from. Because the two DocTypeData objects were distinct, the equals() method had been returning false.


This reminded me of something I've always known about (well, ever since I read Astel's TDD book) but have never used: EqualsTester

Has anyone used it? If someone has, do you think it was worth it? Is anyone aware of a "fully automated" version which would use something like reflection and CGLIB to run the EqualsTester on every class in the codebase providing a no-arg constructor? Would it even make sense?
 
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think this was implied in the above thread but in case anybody doesn't realize it you can feel free to over ride the equals method if you do have a custom data structure. I've done that before and it worked really well.

In code I had written last year I was able to refactor it and re-tested using JUnit and when it was green it was clean - it worked great and gave me a level of confidence about code changes I had made. I knew they didn't have side effects because of my unit tests.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

EqualsTester on every class in the codebase providing a no-arg constructor? Would it even make sense?


I think it would be useful. JTest has rules that flag when you implement an equals method wrong or if you implement equals without hashcode. I can't imagine how to automate it though.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
I can't imagine how to automate it though.


That's a tough problem to solve. Obviously you could instantiate the objects using Reflection and set primitive and wrapper type fields to arbitrary values like 3.5d and "justtesting" but to create meaningful custom type fields might prove to be a bit tricky...
 
joke time: What is brown and sticky? ... ... ... A stick! Use it to beat this tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic