Comments on: How Do You Refactor Untested Code?

By: The Editor

The Editor — Wed, 10 Feb 2010 20:00:24 +0000

The point that Paul Butcher is trying to make is that tests allow you to verify that your (manual) refactoring preserves behavior. Building a extensive tests set is also the advice given by the authors of Refactoring Large Software Systems

By: Carl Lajeunesse

Carl Lajeunesse — Wed, 10 Feb 2010 18:32:30 +0000

I’m completely agree with that.

When you start refactoring without doing tests first, your chance to insert new bug goes up.

By: Steven Kelly

Steven Kelly — Wed, 10 Feb 2010 15:52:57 +0000

Refactorings should preserve behavior, so there should be no problem refactoring without tests. Once you move from automated refactorings to manual ones, or if your refactoring tools don’t always preserve behavior, the situation is more complex.

I think refactoring, bug fixing, and writing tests are actually pretty orthogonal. Doing them in any order will improve things. To say “Without tests, you’re not refactoring. You’re hacking” is hyperbole.

Hacking (in the pejorative sense) when fixing bugs is making quick changes to code to see if the bug goes away, without really understanding what the program should be doing and what is going wrong. Writing a test is a useful way of making explicit a single case of what the program should do. But at the end of the day writing code is where you really demonstrate whether you’ve fully understood the task. Refactoring helps later readers reach that same understanding.