It’s not too late to add tests
I hate it when I don’t follow my own advice.
I’ve spent the last few hours trying to clean up the code of my Wiki, with a goal of eventually ending up with something I can make more widely available.
One big problem. I was lazy when I wrote this. No unit tests. I’m trying to do major changes to the functionality, and there’s nothing telling me what I have, or haven’t broken. You get this interesting feeling in the pit of your tomach when you make a big change, one of those “what have I missed?” feelings.
If I’d written unit tests, I’d have a little green bar to tell me nothing was broken. Of course, what I should do is take time out to write tests now. But…
I know the feeling. SiteMesh was designed with zero unit tests.
It worked and has been pretty stable but it eventually got to a critical mass where it was very hard to add new features, refactor or bugfix without sweating. Inevitably, everytime something was changed, something elsewhere broke, and the “don’t touch that” attitude approach started showing its ugly head.
Recently testcases have been retrofitted and the development has suddenly become fun again. We have a rule on the development team now that every line of production code is required to make the tests pass. If any line of code can be removed/modified and the tests still pass then it is redundant code. This works like a charm.
But… how did we go about retrofitting an application that wasn’t designed test first without serious amounts of refactoring? If you refactor you’re bound to break something without unittests in place but you can’t put unittests in place without refactoring. Bad chicken! Bad egg!
Well, we created an automated regression testsuite. This automatically deploys an example application that uses of all SiteMesh’s features to a container and tests the end result using raw HTML. This testsuite told us what we wanted to know - that all of SiteMesh’s features were working as expected.
This regression testsuite by no means enables the benefits of test first development but it does allow the codebase to be refactored into a state where fine grain unittests can be used thereby giving developer confidence knowing the app works 100%.The entire testsuite only took a few hours to create (which were admittedly dull) but it saved hundreds and put the dreaded ‘rewrite’ word out of my head. I think the other developers will testify how crucial the regression testsuite has become.
So take the time out to write tests! Even spending a few hours writing a few high level tests can pay off quickly, not just in quality and productivity, but your own happiness.