In this installment of using the Golden Master Technique to perform effective refactoring of a legacy codebase, Katrina Owen uses several well-known approaches to tease out simple concepts from complexity.
The refactoring techniques remove parameter and inline method helped strip away cruft and confusion, allowing concepts to emerge. Refactoring using extract method, rename method, and rename variable encoded the exposed concepts into the codebase itself.
In the previous article, we used the golden master technique to dump the entire body of an HTTP response to a file. This file was a quick-and-dirty validation that our changes did not alter the behavior of the system.
With the test in place, we removed logic from the view templates and ultimately deleted a whole template, calling one template from two different controller actions. This refactoring improved the view layer, but in the process it added more logic and more duplication to some already janky controller actions.
In this article, we’re going to turn our attention to the controller.
This entry is part 1 of 3 in the series Golden Master Testing View templates should be simple. They should, in fact, be so simple that there is no point in calculating a complexity score for them. In successful applications, however, this is often not the case. Logic sneaks into the templates unnoticed while everyone’s […]
Too often we take leaps, not steps, while refactoring. However, while we’re hacking away at something which we just know in our gut is going to work (eventually), the tests are failing.
That is, if we’re even running them.
One of the challenges of refactoring is succession—how to slice the work of a refactoring into safe steps and how to order those steps. —Kent Beck
A safe step is one which does not cause the tests to fail.
This refactoring drill focuses on succession, repeating the act of choosing a tiny, safe step over and over again, with an automated test providing continuous and immediate feedback.