Refactoring: The Golden Master Technique

It’s a beautiful, cool morning; you slept well and feel ready to tackle some refactoring. What a noble intention!

There are some safe refactorings, that is, modifications based on the abstract syntax tree (AST). These are “low-hanging fruit” that need to be picked, assuming, of course, that a type system is in place—a friendly nudge to JavaScript enthusiasts who say, “typing is too restrictive”: give me a break.

Aside from that… yes, we’re itching to separate the responsibilities of this function/class that does everything (God class).

Why regression tests are hard to write

But from there on, we have to be very careful: behind every action hides a regression, lurking in the shadows, ready to pounce and snickering at the thought of taking down production 😈👻

How can we avoid them? It would be nice to have a safety net. And what’s it called? Tests. Very well, let’s write some tests, then.

Except it’s not that simple: the code wasn’t designed to be testable. How do you read the value of this state if it isn’t exposed? How do you mock this dependency, given that nothing is in place for that?

Let’s frame the problem: we want to “capture” the application’s behavior without coupling the tests to the implementation, since the latter is going to change.

One approach would be to sprinkle the code with logs. But a log like { id: 171932, name: "Paul", balance: 1400, unit: "EUR", date: "31/10/2022"} will quickly become a problem, because this log reflects the current model and implementation, which is precisely what we’re trying to refactor.

In contrast, a log like Paul has a bank account balance of €1400 on October 31, 2022, written in natural language and in purely business terms, will help us much more.

The idea is to ensure the stability of the logs throughout the refactoring. And with that, we’ve just reinvented the Golden Master method.

Golden Master: Freezing business scenarios using business logs

The method has three steps:

Creating the master: a set of business logs that comprehensively capture the application’s behavior. The choice of business scenarios is therefore crucial. This step generally requires several iterations, as it also serves as a phase for discovering the application. During this phase, we’ll rely on code coverage, which we aim to be 100%. But be careful: this is a necessary but not sufficient condition. We may have achieved 100% code coverage through tests without having explored all of the application’s execution paths.
Refactoring: Of course, we don’t just dive headfirst into a major refactoring. We take the time to explore the codebase, then proceed in small increments. This is called the Mikado Method. After each refactoring, we rerun the entire suite of tests. The business logs generated in this way are compared to the master, and even the slightest difference is a sign of a regression. During this step, it’s perfectly fine to write tests specific to the new implementation, or even to let the tests guide you (Test-Driven Development). In other words: “Go for it!” 😁
Removing the master: these tests are, by their very nature, temporary. They should be viewed as scaffolding, which we take down once the building is complete. We’ve taken care to add unit and integration tests for the new implementation, so we can remove the Golden Master tests without losing any code coverage.

There you have it. That’s the Golden Master. Nothing more, but it still takes work to get there. These refactoring methods are covered in detail in my course “The Art of Refactoring,” but mastering them requires a good deal of practice, so… get typing! 💻