Great Experience with Unit Testing

This weekend I planned on stopping in at work for an hour or two to clean out some simple things on my TODO list. Unfortunately, upon opening my email, I was greeted with a message that our overnight build/run system had failed. In particular, a unit test suite for a library that I had created had failed to pass. The email also indicated that our application had significant changes in output from its previous run, something that wasn't expected for any changes that had been checked in the past day.

The unit test failure struck me as quite odd since the code in that library hadn't changed in over a year. I reran the test suite in my development environment, found the test that was failing and noticed that an output string I was expecting had changed. This failure gave me an immediate clue to where the problem was introduced, and with great satisfaction, I was able to track down the problem in no time.

As it turns out, my unit tests were not the only code expecting to see that same string value. Another major library in our system, which controls output functionality, had failed due to the changes that had been made. This library is much more complicated and does not yet have test coverage.

What I found significant about this experience, was that my unit tests had caught an error in functionality outside of the library they were testing. The library I wrote is pretty trivial, and I actually wrote the tests after writing the code (tut, tut) to try and introduce unit testing to my team. So an exercise that I felt was pretty academic at the time, had a significant practical payoff. Had I never written those tests, I would have spent much more time tracking down the change that had caused the problem.

Lesson learned: Unit tests not only test the primary functionality being tested. They can also test secondary functionality that the primary functionality depends on. Even if a test seems pointlessly trivial, its worth writing as it may uncover problems in other areas of the system.