Your Unit Tests Should Mind Their Own Business

As the unit testing debates continue on my project, I can't help but noticing that people are spending all sorts of time pontificating over the right way to unit test, without stepping back to consider what they're trying to achieve with unit testing. And because they don't know where they're going, they're not reaching any conclusions on how to get there. Sound familiar?

There are actually a number of fabulous reasons for doing unit testing:

1. They help us think about our design in a way that we might not otherwise.
2. They lead to cleaner code because it's often easier to re-factor our code to be more testable then it is to write unit tests that exercise obfuscated or otherwise hard to access code.
3. They validate that our modules are behaving correctly.
4. They provide a safety net to ensure our existing modules continue to function properly as our application evolves.

These aren't all intuitive and so a lot of people will only consider #3 when they think about unit testing. And yet, what's interesting is that #3 typically provides the smallest return on our unit testing investment because we tend to find WAY more defects through #1 and #2 as we work out how to develop our tests, and then of course in #4 as we continue to change our code over the application's lifetime. And, unfortunately, by focusing only on #3, it can lead us to make some faulty decisions when we try to reason about the best way to do unit tests.