The Myth of Unit Test Value
I’m writing this blog post because someone on the internet is wrong…
[](http://xkcd.com/386/)
I know this is oversimplifies the argument a lot of people are making but I think that saying unit testing are just as valuable as production code is symptomatic of an unhealthy way of looking at unit tests. Unit tests are valuable for a few reasons:
More accurately, I saw an old comment about unit testing that I frequently hear hardcore testing advocates say. I'm not calling out the specific person since I suspect his understanding of the value of testing is more subtle than one sentence and that we may actually agree in practice. If you really want to figure out who said it here's the [SO thread](//stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565).
The basic comment is this:
> _Unit tests are just as important as production code._I'm going to use pseudomath to explain why I think this is totally wrong. I'm going to ignore a lot of things in order to simplify.
Since I believe the point of software development is to build tools that improve the lives of the people paying for the tools (you, your boss, your customer's shareholders, etc) the basic equation for the value of a software product would look like.
> CodeVal - CodeCost = NetIncreaseInHappinessIf unit tests are equally valuable to production code and we ignore everything else then the formula for CodeValue is:
> ProdCodeVal + UnitTestVal = CodeValIf the above is correct we could simply double our unit test coverage, scrap our production code altogether and have just as good of a product! Yay!
This is totally wrong. And also bad math.
- Your production code is more likely to work right (+ProdCodeVal)
- Other developers can more easily understand what’s going on (-CodeCost)
- Your code is more maintainable (-CodeCost)
- You get to look down on people who don’t test (+EgoVal)All of those (and more) are great but they are all factors weighing into the value or cost and not inherently valuable on their own. Unit testing is a tool, not a end product. Like any tool, you should only use it if it helps make the end product somehow better than it would be otherwise. That’s why most of us don’t test our databases. That’s why you might want to test that a complex function does what you think it does.
I like building things. A screwdriver is a great tool for building things when you need a screwdriver. I don’t use a screwdriver when I need to hammer something or (hi @mattdarby) when I want to see if a circuit is hot.