I don’t think many people will disagree with the practice of adding unit tests and striving for 100% code coverage. However, I think there is a very real downside to it. It wasn’t so long ago that I was faced with making a change to some code that had zero unit tests and a fair amount of coupling. I hated making that change and it was the coding equivalent to treading on egg-shells. After a period of refactoring and creating unit tests the story is better…or is it? I no longer have such a fear when it comes to changing that code, I know that even if I don’t find the correct unit test to run the continuous integration process will run it and complain if there is a problem. However, I am now faced with a different dilemma, every code block I add I need to create a unit test for it. There is no escaping the fact that it does take some extra time to write the tests and it does impact on the here and now. Of course I will write them because it will be better in the long run but my real fear is that you start to code differently because subconsciously you start to avoid doing things that require you to write extra tests. Consider this very simple example of checking an age…
totalAges = newAge + currentTotal
Now really I should throw a specific exception if the age is negative…
if newAge < 0 then throw new AgeNotValidException
but if I do that I’ll need to write another unit test to ensure that this exception is raised. The little devil on my shoulder says, "but that’s not likely to happen is it, no need to do that, it’s not in the specification, why add it, look at all the other code you’ve yet to write, etc, etc". It is a matter of pride in your work and ultimately you should always do the right thing, but I can’t help feeling this is like red-tape. I wonder how much Test Driven Development dynamic language developers will use?
IT Bytes 