Unit Test Crazy!

So, I never really worked in an environment where unit testing was the norm. I’ve been trying to pick it up on my own for a while now and, in some respects, I think I’m doing a good job. I get the basic idea, but I’m not in tune will all of the tools and libraries that are actually available and heavily used out there in the real XP world.

So today I sort of stumbled upon and started looking at mock object libraries, mostly in Java (since I have a feeling that it’s the Java community that has the most robust and mature unit testing libraries), and I was impressed by the whole idea. It makes sense, so much so that I “implemented” it to test my generated code. But what I do a lot with a lot of custom code, logging and XML comparisons, they do with these mock objects, and they don’t need external files to do it. It’s all really, really cool.

So cool that, for a while today, I was thinking about replacing the XML logging system in my generated code tests with mock objects. But I still have an interesting problem. If I use mock objects, I can make the test code self contained, meaning that the generated tests can test the generated code and the pass / fail result tells me whether my generated code worked. But, this does not tell me whether or not my generated tests are testing everything I want them to, which results in a “testing the tests” problem. I’m not sure how to solve that one yet. For now I may just have to rely on my tests as they stand and try to figure out some way to make sure that I have at least key features tested in the unit tests.

In addition, to this, though, I was researching unit testing against databases (another thing I have to do frequently). Here, I got confused about best practices. Should I create a mock object for the database connection and test against that, or should I use something like DbUnitto connect to an actual database? My compromise, I think, is to do both. Test against the mock object to make sure that, from a unit perspective, the base library works and calls what I expect it to on the database. Then, use DbUnit to test against the actual target database platform (or platforms) to make sure that things get to where they’re supposed to go. This, of course, is a functional, not unit, test, but just as (if not more) necessary, since it actually tests what would happen in real world integration.

So, today just made me realize I have a lot to learn about unit testing. Any suggestions on where I can learn more?

Bookmark the permalink.

2 Responses to Unit Test Crazy!

  1. David Ludwig says:

    I started getting heavy into unit testing over the past year or so. I’ve found the c2.com wiki to be a good asset, as it has a lot of information on unit tests. The best resource I’ve had so far though has been Kent Beck’s book, Test Driven Development: By Example.

  2. Jeff says:

    Hey Dave!

    This book looks great. It’s on safari so I can start reading it right away, which is always good. Thanks for the suggestions!