Sunday, October 14, 2007

Unit Test Discomfort

Unit testing is not one of my strong points. I'm currently reading several books whose central claims are that unit tests bring stability to code, save developers time when refactoring and that once one becomes test infected that they're fun. The claims may indeed be true, and that's why I've been reading about unit testing. I want to believe the claims. Michael Feathers claims that legacy code is simply code without tests. That's rough. Really rough. It means that my code is “legacy” even before it has been committed to version control. Before Michael's book I thought of legacy as being code written in an ancient language, or perhaps a system that has been around for years. Interpreting code without tests as legacy brings a new perspective. Even though I comprehend and agree with the tenants of unit testing, I have trouble brining it into my daily work.

According to the literature, good unit tests run quickly so as to give quick feedback to a developer. Most of the books I have read claim that a unit test should run in less than 1/100 of a second. Typically tests are not to include database access, or interaction with other systems. They simply exist to test a given class or function. Unit tests are there to verify that a piece of code will produce expected results given a set of inputs. If a developer is doing his/her job it should be the situation that a test case is crafted to test each branch of logic in a unit. Given the above constraints, my mind draws the conclusion (perhaps naively) that unit tests are best suited to check user defined algorithms and to do bounds checking.

My struggle with unit tests begins with defining what is appropriate to test. If you are building a simple database driven web application where do the tests belong? I acknowledge that if there is an interesting algorithm or function to verify that would be an appropriate use of a unit test, but what if the work being done is very simple. My framework of choice has unit tests for all of it's moving parts, so I don't really need to re-test the plumbing. I find that there are a lot of interesting conditions that I would like to test with regard to getting data into and out of the database, but the principles of unit testing claim that the database is out of scope. I find that there is a goodly amount of logic happening in the JSP by way of JSTL tags and Javascript, but I haven't seen any really great unit testing tools for that either. Does this mean that I just haven't built a sufficiently interesting web application? Am I placing the logic in the wrong places?

I've still got some reading to do, and my mind is still open to the idea. I would really like to join the happy group of people who swear by some form of test driven development. The advantages appear to outweigh the costs of maintaining tests. I would like to know how to fit unit testing into the work that I do. It just appears that there's a mis-match between the way that I develop and the concepts that are being discussed in the literature.

No comments: