Kevin Conroy: Unit Testing

By Kevin Conroy
Back to the Main Page
Last updated September 15, 2004

Yes, at first glance it seems like unit testing is more trouble than it's worth. However, it does things that simple asserts cannot do. For instance, although an assert will help you make sure that your pre- and post-conditions are correct, it does not really show you that the function behaves as you would expect it to when called from another function.

The idea of unit testing is not just to test the pre- and post-conditions of your data structure which asserts can do. Rather, it is meant to have you set up several tests for the more complicated functions so that you can define various parameters to be passed into it and various return types/exceptions which you expect to occur.

For instance, consider a PM1 Insert/Add function. You can have plenty of asserts in there which will test that you do in fact have a valid PM1 quadtree. Perhaps you meet all of the definitions. But you forget to return true. Your command parser expects that it will return true on a successful insert operation and you're left scratching your head as to why this occurred. Not a huge error, but it is a good example of the problem unit testing is trying to solve.

Unit testing is attempting to USE your function as it would be used by OTHER parts of the program. You can write a random data generate class to randomly generate numbers and strings (if you do this, set it up so you can define a range like "give me a random number between 0 and 1023 inclusive" or "give me a string of a random length but no greater than 10 characters"). Your unit tests can use this randomly generated data as parameters to your functions. Put that in for loop with a count of like 1000 and not only do you have an instant test that your function works as expected, but the random data generator allows you to test extreme cases that you probably would never think of on your own. Write enough of these with enough random data and you can just hit the "Run" button and watch your PM1 quad tree try to insert 100,000 randomly selected points and/or lines and see how it behaves. Only in such a situation will you ever be able to convince yourself that your PM1 is working properly.

So unit testing not only gives you the same things that lots of assert do, but it also gives you stress testing for it. It lets you make sure that the API of your class behaves the way you think it should so that way you won't have any errors introduced by integrating working classes together with non-working APIs. It also makes sure that you have a good design before you've forgotten how you wrote the class. After all, if you realize that you need to add several more parameters to get all of the data that you need to your insert function, better to do it right after you finished writing your insert function (or if you wrote your unit test first, which is the idea of Test Driven Development, BEFORE you wrote your insert function), then you won't waste time trying to relearn your own code.

Unit testing is a bit of a pain in a time-sensitive situation. It takes a few extra minutes which can seem pretty tedious. Thankfully, there are MANY tools out there which integrate with various IDEs which help you automatically write the skeleton code for your unit tests, saving you those few annoying yet precious minutes. If you want to do unit testing, get JUnit and see if there are any add-ins for the IDE that you are using that can help you automatically generate some test code.

I think of Unit testing like commenting my code. Yeah, it's a real pain when you first start to do it, but once you see how it will save your butt and lots of time down the road, you'll WANT to start doing it on all of your projects. (And yes, as much as I'd just love to move on to the next class, I do force myself to sit there and write unit tests. Just keep telling yourself that it's worth it no matter how anxious you are to get the primary output ;-)

Check out Google, of course, and also search www.sourceforge.net and look at the links on the JUnit site. (SourceForge is a community of open source programs and I know for a fact that there are lots of unit testing related projects because I've been using several of them at work.)

Writing good tests is almost as hard as writing correctly working code. But by writing tests you will think about your code more and catch bugs while the exact implementation of a particular function is still fresh in your head, allowing you to fix many bugs before you even compile.

By Kevin Conroy
Back to the Main Page
Last updated September 15, 2004