Chapter 31
Refactoring
These patterns describe how to change the design of the system, even radically, in small steps.
In TDD we use refactoring1 in an interesting way. Usually, a refactoring cannot change the semantics of the program under any circumstances. In TDD, the circumstances we care about are the tests that are already passing. So, for example, we can replace constants with variables in TDD and, in good conscience, call this operation a refactoring, because it doesn’t change the set of tests that pass. The only circumstance under which semantics are preserved may actually be our one test case. Any other test case that was passing would fail. However, we don’t have those tests yet, so we don’t worry about them.
This “observational equivalence” ...
Get Test Driven Development: By Example now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
