The First Refactoring Step

These patterns are intended to be used by the community so it is the community the best suited for decide their content.

"You should think of it (having tests before refactoring) as walking a tightrope without a net. If you are good at walking a tightrope, and it's not that high up, then you might try it. But if you've never walked a tightrope before, and it's over Niagara Falls, you probably want a good net" [1].

Pattern Name: The First Refactoring Step

Problem

How do you make sure you are ready to follow a refactoring process?

Context

You are developing software and you want to make some refactorings before continuing coding.

Forces

Solution

Before you start refactoring, check that you have a solid suite of tests for the section of code that will be changed.

Resultant Context

The use of this pattern together with the BacktrackIfRefactoringFails pattern give you the security you need to change a working program because "the tests provide immediate feedback when we broke something in the code" [4]. You can apply TestEveryRefactoring and RefactoringInVerySmallSteps to go forward.

Rationale

A set of tests is essential to applying refactorings because even though you follow RefactoringInVerySmallSteps to avoid chances for introducing errors, "(...) you're still human and still make mistakes" [2]. Also "even if you are fortunate enough to have a tool that can automate refactorings, you still need tests (...)" [2] because you could use the wrong refactoring to solve the problem.

Origins

The name of this pattern came from a subchapter in the Martin Fowler book [2] titled "The First Step in Refactoring". There, Martin exposed his point of view about the importance of having suite of tests before refactoring.

Eric Burke and Brian Coyner wrote the following in their cookbook: "Refactoring works hand-in-hand with automated unit testing. Before you refactor code, make sure you have a working unit test on hand" [3].

Acknowledgments

References

[1] Bill Venners. Refactoring with Martin Fowler. A Conversation with Martin Fowler. Available at: http://www.artima.com/intv/refactorP.html. 2002. Last confirmed: July 01, 2004.

[2] Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. Refactoring: Improving the Design of Existing Code. Addison - Wesley, 1999.

[3] Eric M. Burke, Brian M. Coyner. Java Extreme Programming Cookbook. O'Reilly, 2003.

[4] Jonathan Rasmusson. Introducing XP into Greenfield Projects: Lessons Learned. IEEE Software, 20 (3), pp. 21-28. May / June, 2003.

Author: SantiagoValdarrama

See Also:

Since most code doesn't have any tests, this means most code can't be refactored. But if you just decide to write tests, you'll discover that many systems are hard to tests if you don't start testing until after the system has been built. In practice, people write a few tests, refactor a little, write some more tests, refactor some more, etc. But it is still a pain in the neck. Refactoring is much easier if you have good tests. -RalphJohnson

Considering a big refactoring, such as decoupling conditionals (say for a database backend) strewn all about ugly code with no tests being refactored into a strategy pattern, there is no problem with code a little test, do a little refactor, commit, code a little test, do a little refactor, commit. It works well, from experience (http://eraserhead.net/sugarsuite-postgres/). --JasonFelice

CategoryRefactoring CategoryPatterns
EditText of this page (last edited December 5, 2005)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006