The question ‘do we really need to test constructors?‘ led me to understand that what 100% code coverage means and why we should strive for it.
Previously I’d always stated that it’s impossible to achieve 100% code coverage. Because 100% coverage means 100% coverage of that you believe to be the system’s functional paths. In other words: it is not 100% in reality. And it’s highly likely to people would write useless tests to reach that 100%.
It all began with a report that showed test is required for constructors. This is when the question came up: do we really need to write tests against constructors?
We know that the constructor is called before any other methods, and its execution cannot be stopped. Ideally, constructors should do nothing, which is an important rule we should enforce for the Single Responsibility Principle, but there are cases when constructors need to do some work.
Some state that all constructors definitely should be tested, and not just because Sonar forces you to do so. Even when you have a default constructor, you should test that it can be called. Or what if later on the class is changed, perhaps it becomes a singleton, for example, then the test should fail in that case to alert that change. There is a debate between people whether it is needed to test empty private constructors that belong to a final class, just for the sake of a code coverage tool. They say that it generates noise in the test suite, so they go with eliminating noise from the coverage report.
So now you created meaningful rules for the report that generates a “100% result”. Yay!
Why enforce it?
This is where psychology comes into the picture! Yes, it’s the good old psychology again.
Have you heard about the Broken Windows Theory?
Let me cite from Wikipedia:
James Q. Wilson and George L. Kelling first introduced the broken windows theory in an article titled “Broken Windows“.
Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken. This is as true in nice neighborhoods as in rundown ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers whereas others are populated by window-lovers; rather, one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing. (It has always been fun.)
As soon as we allow untested code to be merged in, it has the message that testing is not that important, and eventually more and more untested code gets in. Which is bad. For everyone.
Never forget that a high code coverage number itself doesn’t improve code quality. 100% code coverage does not mean that there are no more bugs in the code.
So next time whenever I’m asked about 100% code coverage in an interview there’s a story to tell.