Daily Archives: February 28, 2008

Unit testing benefits programmers who are already good

In order to kick my unit testing skills up a notch, I’ve been reading a lot about it lately. Today I had the thought: “Unit testing only helps already-good programmers.”

My reasoning is that bad programmers are going to write bad tests, or not enough test cases, or bad test cases, or won’t take the effort to refactor their code when necessary, or won’t realize their code reeks, and so on and so forth.

The message from unit testing, and the XP camp in general, is that well-factored, object-oriented, testable code is key. But don’t those criteria presuppose some fairly intense skills on the part of the programmers? Merely introducing unit-testing into your processes won’t automatically improve the quality of code if someone has no clue.

This is a depressing line of thought. It’s not entirely true, however.

It IS possible that enforcing a rule on unit tests will “inspire” inexperienced developers to improve their code. Once they see the beauty of automated unit testing, hopefully some will realize that their code was NOT testable, NOT pretty, NOT well-factored, and start taking steps to change that. The knowledge to do that (why and how), however, will have to come from somewhere else. And since they’re not a good programmer, will they do this?

For these people, then, unit testing is of little benefit–chances are the code is of such low quality that the tests will just conform instead of try to break it.

You can’t teach someone the vision of unit testing without teaching the vision of a lot of other things as well. It doesn’t make sense otherwise.

A programmer who already understands how to build well-factored code is going to use unit tests in an entirely different way than someone who doesn’t understand them. To these people, it’s a way of verifying that it works to spec, and that it’s safe to change the implementation details without destroying the system.

I got into unit testing because I’m a good developer. It didn’t make me a good developer–it made me a better developer. (I said good developer, not great. I’m good because I realize that I always need to improve, and I take steps to do so, not because I’m a genius.)

That last paragraph and parentheses deserves more attention. How do you define a good programmer? Are they innately good, or are they good because they do certain things? Do you unit test because you’re a good programmer, or does the act of unit testing make you a good programmer? Is there a paradox here? Are both true? Neither?

Obviously, there aren’t just two kinds of programmers: 1) good and 2) bad. There is a spectrum. Obviously, again, just doing something doesn’t mean you’re automatically good or better, either. So I think you have to unit test because you’re a good programmer (or someone is forcing you, which is a different topic altogether) already and not the other way around.

I believe being a good programmer must come from within you. Becoming a better programmer can be done with the help of education, tools, and processes.

(Unit testing is just the topic I’m thinking about lately–you could replace it with any practice and the ideas are still the same.)

Technorati Tags: ,,


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code by Ben Watson. Available now in print and as an eBook at: