Refactoring changes code without changing its functionality. Renaming a method or splitting one large method into smaller calls counts when behavior stays the same. The payoff is code that is easier to read, maintain, debug, and change. section 1.10.1
Refactoring is not feature work: add functionality by changing production code until a test passes, then improve the code’s structure without losing the behavior already proved. In test-driven development, tests provide the safety net for redesigning both production code and tests. section 1.10.1
Keep refactoring safe by working in small increments:
- Make one small structural change at a time rather than attempting a large rewrite. section 1.10.1
- Run all relevant tests after each change to catch behavior accidentally broken by the restructuring. section 1.10.1
- For legacy code with no unit tests, first add integration tests against the real system to establish the working behavior. section 12.3
- After a large refactoring, replace most broad integration tests with smaller, more maintainable unit tests. section 12.4
Protecting a legacy configuration change
A C++ XML configuration manager had no tests and was difficult to isolate from dependencies. Integration tests first saved and loaded real configuration data, establishing existing behavior. A further test exposed a missing attribute; after adding it, all three tests passed, showing that the new feature had not broken the old behavior. section 12.3
Refactoring for testability can be hard when existing code lacks seams for replacing or extending components. Start with components that are easier to test when a team is gaining confidence; before broad changes, preserve important behavior with integration tests. section 12.0 section 12.4
