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:
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?
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?