Unit Tests Are Misunderstood

I think some of the misunderstanding of unit tests, is that people don't fully grasp the purpose of unit tests. I often hear things like we don't really need unit tests if we have end-to-end and integration tests, or why do we still have bugs if we have all these unit tests. This really misses the power of writing unit tests.

In the book Growing Object-Oriented Software Guided By Tests (if you haven't read it, I highly recommend it). They explain the difference between internal quality and external quality and how the different types of tests relate to each one.

Higher external quality, which is more what the customer sees, being greater as the test is closer to an end to end test. While at the same time having lower internal quality, which is the state of the code.

A Design Activity

Since writing unit tests is more about internal quality, it is more of a design activity, even if you write your test after, but just not as much.

In order to make code testable, (*which I will expand on in another post), it must be structured in a certain way. Good unit tests steer us in a direction to make the code more cohesive and loosely coupled. And that is the essence of TDD and unit testing, it allows us to easily change our code to adapt to changing requirements, new features, or just better designs.

But we have all been in code bases where the internal quality slips aka Technical Debt, so is it really that important. If we are only focused on what the customer wants, and the customer is happy, does it matter that much. In the short term probably not. However, as the internal quality slips, it becomes harder to add features or not introduce bugs. This is why we need different types of feedback systems when we are developing code, each type of test has it place. In the end we must balance delivering today, without sacrificing our ability to deliver tomorrow.