Some Questions About Writing Good Tests

[Corey McGlone]

Okay, I've been hearing about test-driven development for quite some time, now. I've tinkered with JUnit off and on for a couple years. Unfortunately, no one around me has any experience with stuff so I'm basically trying to teach myself. Anyway, a new project came my way a couple days ago and I decided that it would be a perfect opportunity to try test-driven development and see what I thought.

So, last night, I started doing some development. My application is pretty simple - read in some XML, allow the user to manage the XML graphically, and then spit out the modified XML. (There are a few more kinks, but that's the basic idea.) So, I wrote a class that will handle reading and writing the XML files and a test bed to go with it. I also wrote a class to contain the XML data in a business object so that I can deal with it as a useful object, rather than XML text. Again, I wrote a test bed to go with it. Here are some of the questions I ran across along the way...

1. When testing the XML file reading and writing, how much testing is enough? For the reading, I essentially read in the document and test to make sure that the root node has the correct name. Is that enough? Now, in this case, I'm making use of dom4j, so I don't want to spend my time testing their code - I just want to test my own. So, basically, I test to make sure that I read in the right file (by checking the root node name) and, as long as that's correct, I assume the dom4j package will get the rest correct. So, is that enough testing? How about when I write a file? Basically, I just write a file to the hard drive and then make sure it exists. Do I need to open the file, read it back in, and check the contents? Basically, I'm wondering how far I need to go with this testing.

2. When I read in the XML file, I take chunks of that file and store them into business objects. Then I can deal with them logically. Well, one of the things I wanted to test was the creation of one of these business objects based on an XML element. So I wrote a test that calls a contructor that takes an Element object. But, then how do I test that it made it properly? Well, to test that, I created another business object using the default constructor and then set the fields individually. Then, I use the .equals() method to compare the two. That, of course, required me to override the .equals() method, which, in turn, required me to override the .hashcode() method. For the testing, it seems to work great. The thing is, though, is that I don't think I'd ever use the .equals() object on these objects in the actual application. Perhaps I will, I'm not certain yet, but I don't suspect so. So is there a better way to do this? Right now, I'm doing roughly this:

MyBusinessObject mbo = new MyBusinessObject(myXMLElement);
MyBusinessObject mbo_copy = new MyBusinessObject();
mbo_copy.setField1("1");
mbo_copy.setField2("2");
mbo_copy.setField3("3");
 
assertEquals(mbo, mbo_copy);

That works, but it requires me to write two methods in my business object class that I wouldn't have had to otherwise write. Would this be better?

MyBusinessObject mbo = new MyBusinessObject(myXMLElement);
 
assertEquals(mbo.getField1(), "1");
assertEquals(mbo.getField2(), "2");
assertEquals(mbo.getField3(), "3");

Also, in this case, I'm using a file as input to my test. Is it good practice to have a "test file" somewhere that will never change, so that my tests will always have the same input?

I know, I've got a whole slew of questions thrown in there. If anyone has any good insight into any of these, I'd appreciate and advice you might have. Also, as a final question, I'm going to need to start writing the GUI soon. I plan to use Swing. Any suggestions on a good testing package for a Swing GUI?

Thanks, all.

[Eric Nielsen]

Originally posted by Corey McGlone:
Also, in this case, I'm using a file as input to my test. Is it good practice to have a "test file" somewhere that will never change, so that my tests will always have the same input?

I'm rather new to TDD as well. Most of my learning came from Astel's book. There's two chapters where he deal with saving/loading data to a file. He shows ways of creating a temp file from known contents in your test setup with the file auto-deleted after the test. This seems like a better solution than having a "test file" as the important information stays contained in the test case.

I know, I've got a whole slew of questions thrown in there. If anyone has any good insight into any of these, I'd appreciate and advice you might have. Also, as a final question, I'm going to need to start writing the GUI soon. I plan to use Swing. Any suggestions on a good testing package for a Swing GUI?

Thanks, all.

I'm using the Jemmy package from NetBeans to drive the testing of my Swing GUI, again following the examples from Astel's book.

[Ilja Preuss]

1.

Which logic do you think could break regarding the saving to and parsing from a file using DOM4J?

2.

I generally don't have any problems with writing code such as equals (or toString()) just for unit testing. Testing is important, so everything that helps with testing is good.

But in your case, I'd probably go with the latter code. Implementing equals here doesn't make the test any more expressive.

Regarding testing Swing GUIs, the most important strategy is to make the GUI so dumb that it needs as few tests as possible. Google for the "humble dialog" article by Micheal Feathers. For the rest, I'd too go with Jemmy (in fact I've written a chapter about this in the book mentioned in my sig - only available in German, sorry).

[Michael Duffy]

I agree that writing equals and hashCode make far more sense here. When I do that I add tests for all parts of the equals contract (e.g., transitivity, reflexivity, etc.) to make sure I've implemented equals properly. If I also implement Comparable I'd add tests to make sure that compareTo complies with the contract for equals in the appropriate cases.

Test your code, not the libraries you use. I don't try to test Spring when I use it, just my stuff.

A subtle thing happens when you write unit tests: you become a client of your own code. If you start noticing things that make your tests hard to write (e.g., having to check atomic member fields instead of using a proper equals implementation), perhaps your clients will think your code hard to use, too.