This is a quick post, following up on a tweet from a little while back:
Unit testing is for code coverage like exercise is for weight loss. You're actually missing the point.— Michael (Doc) Norton (@DocOnDev) September 30, 2013
A great number of people in the software field appear to think the primary benefit of unit tests is test coverage. Some even talk about them as if they were one and the same. "No need for more unit tests, we have plenty of coverage already."
But code coverage is not the point of unit tests. Code coverage is a side affect. Some would say that the point of unit tests is to ensure a discrete piece of code does what you intend. This is a benefit. And a significant one at that. Others would say the point of unit tests is to influence design at a low-level. And here I think we're getting closer to the crux of it. Code that is easy to test is discrete, it has few dependencies (if any), and it serves one and only one purpose. When you have an entire system that is comprised of these small, easily testable pieces of code, you have a significantly higher probability that the system itself is malleable, flexible, extendable ... healthy.
The point of unit tests is to help ensure you are building and maintaining a healthy system.