Refactoring

Refactoring is changing the internal structure of code without changing its observable behavior. The behavior-preserving clause is the whole definition: a change that alters what a caller can observe is not a refactor, it is a rewrite wearing the word as cover.

A wrinkle worth stating plainly, since it is easy to misreport: refactoring is not one of the thirteen primary practices in XP‘s second edition. It was a named practice in 1999 and was absorbed into Incremental Design in 2004. It remains everywhere in the method, as the third step of the Red/Green/Refactor cycle and as the mechanism by which incremental design improves anything, but it stopped being an item on the list.

Its relationship to tests is circular, and that is the point

Refactoring needs tests: without them, “behavior-preserving” is an assertion rather than a check. But the tests must be the right kind. A test that asserts on internal structure fails when you change internal structure, which is precisely what a refactor does, so a structure-coupled suite converts every refactor into a second, larger editing job and teams stop refactoring. That failure mode is the entire case for structure-insensitive tests: a behavior-preserving refactor should never change a test’s result.

So the two practices hold each other up. Tests make refactoring safe; behavioral tests make it cheap.

Signal: you can name the refactor you performed, the tests stayed green throughout, and you did not touch a test file while doing it.

Sources

• Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley, 1999; 2nd edition 2018): the book-length treatment, and the source of the behavior-preserving definition.
• Martin Fowler, Test Driven Development: refactoring as the third step of the cycle, and neglecting it as the most common way to get TDD wrong.
• Martin Fowler, Is Design Dead?: disciplined refactoring as one of the practices that makes evolutionary design viable.
• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd edition (Addison-Wesley, 2004): the published table of contents shows no Refactoring entry among the primary or corollary practices.