Working Effectively With Legacy Code — Mechanics of Change(Part 1: Chapter 5)
This is Chapter 5 of the Working Effectively With Legacy Code series. If you haven’t read the previous Chapter 4.
Part 1: Mechanics of Change:
Chapter 5: Tools
You need to know what tools you need when you work with legacy code. You need an editor or an IDE and your build system, but you also need a testing framework.
Refactoring by hand is fine but if the language you are working on has refactoring tools, then it is even more awesome to work with legacy code.
Refactoring(n): A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its existing behavior.
~ Martin Fowler
What is Automated Refactoring Tool:
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
A change is a refactoring only if it doesn’t change behavior. There are a lot of tools that help in automated refactoring in the IDEs.
Refactoring tools should verify that a change does not change behavior.
We should see if the automated tools really check for this behavior. Because, if they don’t check, it can introduce some subtle bugs when you refactor.
For example, Does the tool flag error, when you extract a method, which already exists in the class?; Does it flag if you extract method which is already in base class etc?
What happens to Tests when we perform Automated Refactoring.
When you have a tool that does refactorings for you, it’s tempting to believe that you don’t have to write tests for the code you are about to refactor. In some cases, this is true.
If your tool performs safe refactorings and you go from one automated refactoring to another without doing any other editing, you can assume that your edits haven’t changed behavior. However, this isn’t always the case.
It is a good idea to have tests around your code before you start to use automated refactorings.
Unit-Testing Harnesses
UI-based tests seduce the people to prefer them, but when the test fails it’s too hard to figure out why it failed.
The most effective testing tools are free. The xUnit testing framework is one of the most effective testing frameworks.
The xUnit is a small, powerful design for a unit-testing framework. Example; CppUnit (For C++), Junit (For Java), NUnit (For .NET) etc. The key features are:
- It lets programmers write tests in the language they are developing in.
- All tests run in isolation.
Framework for Integrated Tests (FIT)
FIT is a concise and elegant testing framework that was developed by Ward Cunningham. The idea of FIT is simple and powerful. If we write documents about our system in tables as inputs and outputs, then the FIT framework can run them as tests.
FIT accepts HTML, runs tests defined in HTML tables in it, and produces HTML output for test reports.
The power of FIT is its capability to foster communication between people who write software and people who need to specify what it should do.
FIT helps with acceptance testing.
Fitnesse
Fitnesse is essentially FIT hosted in a wiki. Fitnesse supports web pages that define FIT tests. Pages of test tables can be run individually or in suites and a multitude of different options make collaboration easy across a team.
TLDR; Know your refactoring tools
Part I: Chapter 4:: The Seam Model
PART II: Chapter 1:: I Don’t Have Much Time and I Have to Change It.
References:
- Working Effectively With Legacy Code~ Paperback
- Mock Objects ~ Mockobjects.com
- Refactoring ~ MartinFowler
- Framework for Integrated Tests ~ fit.c2.com
- Fitnesse ~ fitnesse.org
- FIT and acceptance testing ~ academy.real
