阅读中文版本

Golden Master Testing

Golden master testing captures the current behaviour of legacy code as a reference and then compares future output against it, useful before a refactor.

Definition

Golden master testing is the practice of recording a system’s current outputs for a range of inputs and using that recording as the expected result for subsequent runs, especially before changing untested code.

It is applied when refactoring a legacy module whose intended behaviour is not documented and only the existing output is known. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

The technique pins down observable behaviour so a refactor can be proven behaviour-preserving even where no specification exists.

It inherits any existing bugs, so the mastered behaviour is a snapshot, not a statement of correctness; each sample should still be reviewed.

Trade-offs and alternatives

A large brittle baseline is hard to maintain, so scope the recorded inputs to representative cases and keep the file reviewable. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that a golden master asserts the behaviour is correct. Another is that it makes further change unnecessary. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to generating the baseline from the untested code without reviewing samples and to keeping an enormous golden file no one inspects. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Test Flakiness Metrics, Accessibility Tree Testing, The Test Oracle Problem.