Build fluency in the vocabulary of comparing a program's output byte-for-byte against a saved reference file.
0 / 5 completed
1 / 5
At standup, a dev mentions saving a program's expected output as a reference file once, then running the program against the same input in future test runs and comparing its output byte-for-byte against that saved reference file. What is this technique called?
Golden file testing is exactly this: golden file testing saves a program's expected output as a reference file, often called the golden file, once, then in future test runs feeds the same input and compares the program's output byte-for-byte against that saved reference, flagging any difference. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This compare-against-a-saved-reference-file approach is exactly why golden file testing is well suited to programs that produce large, structured output, like generated code, reports, or serialized data, that would be tedious to assert on field by field.
2 / 5
During a design review, the team adds golden file testing for a program that generates large, structured output, specifically because comparing the entire generated output against one saved reference file avoids writing a separate hand-written assertion for every field in that output. Which capability does this provide?
Golden file testing here provides Whole-output regression coverage without field-by-field assertions, since the saved golden file captures the complete expected output at once, and any unintended change anywhere in it shows up as a diff without a hand-written assertion for that specific field. Writing a separate hand-written assertion for every field in a large, structured output would be extremely tedious and would still miss fields no one thought to assert on. This capture-the-complete-output behavior is exactly why golden file testing is favored for programs that generate large, structured output.
3 / 5
In a code review, a dev notices a code generator's output is tested only with hand-written assertions checking a handful of specific fields, with no golden file comparing the complete generated output against a saved reference. What does this represent?
This is a missed golden-file-testing opportunity, since comparing the complete generated output against a saved reference file would catch unintended changes anywhere in it, instead of relying on hand-written assertions that only check the fields someone thought to assert on. A cache eviction policy is an unrelated concept about discarded cache entries. This assertions-only pattern is exactly the kind of coverage gap a reviewer flags once a generator's output is large and structured enough for a golden file to be worthwhile.
4 / 5
An incident report shows a code generator silently produced malformed output in a field no hand-written assertion happened to check, because it was tested only with hand-written assertions and no golden file comparing the complete output. What practice would prevent this?
Adding golden file testing compares the complete generated output against a saved reference file, catching regressions in fields no hand-written assertion checks. Continuing to rely only on hand-written assertions checking a handful of specific fields regardless of how much other structured output the generator actually produces is exactly what caused the issue described in this incident. This golden-file practice is the standard fix once a generator is confirmed to produce large, structured output worth protecting beyond what assertions check.
5 / 5
During a PR review, a teammate asks why the team adds golden file testing on top of already-thorough hand-written assertions for a code generator. What is the reasoning?
Hand-written assertions only catch changes to the specific fields someone thought to check, while a golden file compares the complete generated output against a saved reference and flags any unintended change anywhere in it, making the two complementary rather than redundant. This is exactly why thorough test suites for generators combine both, rather than treating either one as a full substitute for the other.