Search This Blog


Monday, January 7, 2008

It's OK to use Unit Test tools

Unit test tools (such as TypeMock) receive mix responses from the Agile Programming practitioners. Some feel that the existence of such tools enable one to write code with intertwined dependencies and get away with it. Nat Pryce said it best:
If you use unit-testing tools that let you side-step poor dependency management in the design, you lose this valuable source of feedback and, when you find that you do need to address these design issues because you have to modify the production code, it will be much harder to do so. The poor structure will have influenced the design of other parts of the system that rely upon it. The programmers responsible for the change will not understand the code as well as those who wrote it (even if they are the same people). It's far easier to nip these design issues in the bud as you discover them than let them remain to affect the design of the rest of the code.
As much as I like the idea of writing good, designed code that can be tested easily (Testable Object Oriented Design, TOOD), I still feel that those unit test tools are valuable precisely because it enables one to test poorly structured code.

We are not living in a perfect world where the codebase we wrote ( or inherited) is of utmost perfect form. More often than not, we need to work with code that emits strong code smell and that is not designed to be unit tested. In this case, unit test tools enable us to sidestep all the nasty dependencies and test only the thing that we want to test.

The point is, such a tool is very powerful, so powerful that one may indulge in its power and forget to design the code properly.

Let's pause for a moment and think carefully: that's a problem alright. But is that the tools' problem?

Forgoing unit test tools just because it can be misused is no difference from the attitude of throwing the baby out with the water. It's an extreme response.

You have code review right? That should catch poor design. Relying on the possible penalty of not being able to do unit test will not improve your software design in whatever sense. For some developers, not being able to do unit test is tantamount to "no need to test your code". So they have this mentality of throwing the code over the wall for testers to test. The net result? The software quality gets worse.

Unit test tools are good, or even indispensable. Even though it needs to be used with care.

P/S: Roy addressed the same issue here and here

1 comment:

Anonymous said...

It's too late to catch bad design in code review. By that time, money has already been spent developing the bad code and pressure is on to deliver new features. Nobody is going to down tools and clean up code that is working, even if it is badly designed.

That's why it's so important to get the design clean the first time round and get early feedback as to where the problems are.

Programmers avoid tools like TypeMock because they stop the computer giving you design feedback automatically. Why do things by hand (code reviews) when your computer can do it for you?