Recently, somebody posted an innocent-looking question on the JUnit mailing-list, basically saying that he finds unit testing hard, confessing he doesn’t always do it and asking for opinions about whether his situation is normal and if everybody else manages to do testing 100% of the time.
I have to say, even I underestimated the virulence of the responses that followed. I’ll skip the messages along the line of “I test 100% of the time, something is wrong with you” to focus on another response from Robert Martin that crystallizes an extreme attitude that is so detrimental to Java software in general. Here are a few relevant excerpts…
Code coverage for
these tests should be very close to 100% (i.e. high 90s). If you
don’t have this, then you don’t KNOW that your code actually works.
And shipping code that you aren’t as certain as possible about is
That’s a bit extreme, but not entirely untrue. What this statement fails to distinguish is that there are several levels of “unprofessionalism”. I can think of a few that are way more critical than “shipping code that it not covered by tests”:
- Missing the deadline.
- Shipping code that doesn’t implement everything that was asked of you.
- Not shipping.
I don’t know about you, but if I have to choose between shipping code that is not covered or even not automatically tested and one of the three options above, I will pick one of the three options. And I would consider anyone else not doing this to be extremely unprofessional.
If you don’t have this [code coverage], then you don't KNOW that your code actually works.
There are plenty of ways to know that your code works. Testing it is one. Having thousands of customers over several years, consecutive successful releases and very few bug reports on your core functionality is another.
Claiming that only testing or code coverage will tell you for sure that your code works is preposterous.
The argument about "TIME" is laughable. It is like saying that we
don't have time to test, but we DO have time to debug. That's an
This seems to imply that there are only two kinds of code:
- Code that is tested and works.
- Code that is not tested and doesn't work.
There is actually something in the middle: it's called "Code that is not tested but that works".
This kind of code is very common, in my experience. Almost prevalent. And this is also why I am convinced that if other circumstances warrant it, it's okay to write the code, ship it and write the tests later.
It's simple common sense, really: when faced with tough decisions, use your judgment. Your boss is paying you to decide the best course of action with your brain, not to base the company's future on one-liners pulled from a book.