Monday, December 19, 2005

Does Refactoring Make Unit Tests Irrelevant?

I came across a very nice discussion on joel's website (

Argument 1:
I like the idea of using unit tests to help ensure that adding new code or refactoring old code doesn't introduce bugs.
I want to start using the idea, but I can see a problem...
When I'm refactoring, I'll probably be rearranging the "units" of software. If my unit tests refer to the old "units", haven't I just broken all of my tests? So I now have to write new unit tests for my refactored code? New code to test new code -how does that help prevent bugs?
What am I missing here?

Argument 2:
Refactoring as I understand it is rebuilding code within the same unit. Such as rewriting a search function from one algorithm to another that at least in theory is more efficient based on the needs of the application.
However if we ARE changing how units are organized it would have a good chance of forcing a rewrite on unit tests. But then again being forced to acknowledge such a fundemental system change is important as it tends to imply we may be about to break other parts of your application that assume a piece of code is in one particular file/class/etc.

Arguemnt 3:
You'll be writing and fixing tests as you refactor so there is no time when you are writing all new tests or fixing all old tests. You are implementing small chunks at a time and creating/fixing unit tests as you go.

Refactoring requires unit tests. If your code changes breaks the test, then the test has done its job to tell you you have not refactored correctly.

To put it simply:
Refactoring makes Unit Tests ESSENTIAL.

No comments:

Post a Comment