The Purpose of Unit Testing

The way you test software (or don’t) is heavily influenced by your theoretical perspective of its purpose. I’ve learned that, contrary to my initial belief, unit testing is not about finding bugs. It turns out that manual testing is much more cost effective for discovering new or novel bugs than unit testing. TDD and CI die-hards might be bothered by that revelation, but they don’t need to worry. Let’s discuss why.

First, let’s define our terms.

Unit testing is the practice of writing code that systematically exercises individual portions of a target code base to ensure that it behaves in the desired manner. On top of that, Test Driven Development (TDD) is a practice that encourages developers to write the unit test first and then write the code that it tests. In this case, the developer is effectively writing the specification for the code and then fulfilling it in a verifiable way. Ostensibly, this produces code that has a much higher initial quality. In yet another application of unit tests, integration testing is done at a higher level to ensure that software modules play nicely together. You can argue that “unit” testing is not the right word for this, but that all depends on how you define a “unit.”

So, if unit testing is not about finding bugs, then what is it for?

The important word in that statement is “finding.” If your approach to developing software is to write code and then, much later, write unit tests, or simply leave that task for QA to do, then yes, the unit tests will point out bugs in the code. However, it’s possible to pass all the tests and yet still have additional bugs that are not accounted for by the tests. The obvious reason is that there are innumerable ways to misuse code and it’s usually the way we didn’t consider that becomes the problem.

For this reason, we say that unit testing is not about “finding” bugs. Instead, it’s purpose is about designing robust software components that conform to a specification. The unit tests are the specification. TDD is a powerful development practice for designing software components because you specify the behavior up front through unit tests and implement accordingly. This helps to deliver software components that individually behave per the design.

The exception to the statement “unit testing is not about finding bugs” happens when talking about refactoring. In this case, writing unit tests ensures that we do not introduce regressions by breaking existing functionality through new additions or modifications.

All that said, here is a concise table pairing a specific goal with the best testing practice for achieving it: