Coding, Managing and Christianity

Thoughts about coding, managing and Christianity

The Value of Unit Testing

by Chris Ampenberger. Tags: management , coding .
Share Facebook , Google+ , LinkedIn , Twitter

A while back I read an article somewhere where the author made the point that unit tests are of limited value, because many of them never fail. An outcome that never changes contains no information and is therefore of little value, especially considering the the investment required to write them. I unfortunately didn’t take note of the reference and can’t go back to double check, whether what I remember is what the author really said.

Regardless since this article I have been paying more attention to the tests I write. What I found is that when I extend or refactor code, I usually turn first to my automated API tests to make sure none of the interfaces that matter have been broken. Only then do I run the unit tests and fix, what needs to be fixed. This pattern seems to support the authors point, but there are other aspects to be considered.

I don’t practice test driven development, but rather write the code first and then add the tests. I tend to put a little bit of a gap between the two steps, when I can. That fairly often lets me rethink code and I come up with a better implementation.

Unit tests also have a lot of value when Duck-languages (typeless) are used, where not compiler enforces datatypes and method signatures etc. A lot of these oversights can be caught with unit tests.

Then there meeting a certain code coverage number like at least 80% line coverage or 75% of branch coverage that management demands. I have to admit I did the same with my team, because I don’t have the time and in-depth knowledge of the code to make sure the developers have chosen the right unit tests. Therefore I rely on a proxy like line coverage, which is also easy to explain to the higher ups in the food chain. I certainly have to re-think that behavior.

My conclusion so far is that unit tests have their place and value. I will continue to invest in them. When I write code I will use code coverage as a sanity check to make sure I covered everything that matters, but will not force my team to reach some magic coverage number. It is more important to hire excellent developers and trust their ethics to do the right thing.