There are times when software developers are reluctant to write unit tests. I’m not going to dwell on how this attitude is ultimately self defeating, and something monstrous, but there it is. Professional developers are, at times, reluctant to write unit tests. Even though there are so many negative consequences for failing to adequately cover one’s code with clean unit tests, developers sometimes resist unit testing. I know this happens, because I’ve felt that reluctance as well. This is hard for a professional to admit without feeling somewhat dirty, but sometimes we need to admit that we’re lost before we can begin to find our way back.

For me, one of the key reasons I’ve heard the “don’t bother testing” devil make a compelling case while whispering in my ear is that I usually work with legacy code that often has very low unit test coverage. By very low, I mean typically in the range of <1% to 5%.  In these kinds of projects, essentially without any unit tests, developers are faced with the daunting task of writing a substantial amount of new unit code tests just to be able to get to the code branches that include the new code you’re adding or modifying.

Continue reading “A Case For Using The @VisibleForTesting Annotation” →