For a while now, I have been asking, “What is the right amount of unit tests?” There are some debates about 200 tests covering 20% is better than covering 75%, but what does that really mean? I will explore some of that now.
I have been looking at some articles from Uncle Bob, Martin Fowler for some guidance. He makes mention that high unit test coverage doesn’t provide a good indication that you have tested your application. A lower test coverage percentage is better than a higher one, if the number of tests is equal. But I have been thinking, well what is something that can be measured then?
It hit me like a brick, well of course the answer is Cyclomatic Complexity. It makes sense, what are you testing? The different choice your code goes through is exactly what you should be making tests about. Martin Fowler makes mention that if you test a certain part of your code too much, then it makes refactoring a chore. This is why you need to test based on Cyclomatic Complexity, so you don’t test more than what is necessary.
The only other parts that don’t fit into this is testing throwing exceptions. These are the added logic that needs to be accounted for, after testing Cyclomatic complexity. But otherwise, use the ratio of Cyclomatic complexity with the test coverage and unit tests you create. This will give you an even better idea of whether your unit tests are doing what you want.
Note, testing logging sucks and other things that “don’t really matter for business rules”. This should also be taken into account with your test cases.