2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 21, 2010
- Refactor Legacy Code
Retrofitting tests into legacy code is difficult process but can give us the ability to redesign and improve the quality of that software as we go. It is generally a good idea to add tests before refactoring code. Tests serve as a safety net so if I make a mistake in refactoring the test will tell me.
Sometimes we need to refactor code in order to add tests. These are generally simple refactoring or what Michael Feather’s calls “safe refactorings” in his book Working Effectively with Legacy code. Several IDE’s provide facilities for automating safe refactorings. Once tests are added you can do more complex refactoring.
It is always a good idea to make a test fail before making it succeed. How do we do this when we are retrofitting tests into working code? The answer is to temporarily change the working code. For example, if I am writing a test for code that sums 1 and 2 then I’ll hardcode a return value of 1 to make it fail, then I’ll watch it fail and then I’ll back out my change using Control-z and watch the test succeed. This may seem like a pointless activity but you may be surprised at the times you expect a test to fail and it succeeded because of something you weren’t expecting.
If we are going to take the time to clean up legacy code then we must do it in a way that we don’t end up with the same problem years from now. If we want our software to survive and continue to be used and changed then we simply have to start building it with some core engineering practices that support change, including unit tests.
Previous Post: « Test Driven Documentation
Next Post: Is it a Good Design? »