golden fileとは？
golden fileとは、期待される出力のコミット済みの参照で、テストが実際の出力をそれと比較します。
関数が大きく複雑な出力を生成するとき、たとえば生成されたコード、レンダリングされたドキュメント、シリアライズされた構造などでは、手でアサーションを書くのは面倒で壊れやすいものです。golden fileテストは、その出力の既知の良好なバージョンをリポジトリ内のファイルとして保存し、新しい出力が異なればテストを失敗させます。これはsnapshotテストの背後にある考え方と同じです。
golden fileの仕組み
コードを一度実行し、出力を注意深く検査し、golden fileとして保存します。後続の実行は出力を再生成し、goldenと差分比較します。一致すれば合格、不一致なら失敗して差分を表示し、コードを修正するか、変更が意図的ならgoldenを更新するよう促します。
golden fileとsnapshot
この概念は大きく重なります。「golden file」はより古く言語中立な用語で、Goやシステムテストで一般的です。一方「snapshot」はJavaScriptのツールが広めたframework管理版です。どちらも現在の出力を保存されたbaselineと比較し、snapshotはファイル管理を自動化するだけです。
簡単な例
テストはgolden fileを読み込み、生成された出力がそれと完全に一致することをアサートします。意図的に再生成するためのupdate flagも備えます。
want := readFile("testdata/output.golden")
got := Generate(input)
if got != want { t.Errorf("mismatch") }避けるべき落とし穴
- 差分を読まずに反射的にgoldenを更新する。
- レビュアーが検証できないほど大きなgolden。
- 非決定的な出力（timestamp、順序）が誤った差分を引き起こす。
- goldenの変更をレビューせず些細なものとして扱う。
CIにおけるgolden file
CIではgolden fileは読み取り専用です。パイプラインは不一致で失敗しなければならず、決して黙って再生成してはなりません。時刻をstub化しコレクションをソートして出力を決定的に保つことで、誤った差分を防ぎます。これらの比較を高速runnerで実行すれば、大きなgoldenスイートでも素早く保てます。
重要なポイント
- golden fileは、期待される出力のコミット済みのbaselineです。
- テストは実際の出力をそれと差分比較します。snapshotテストのように。
- CIではgoldenは読み取り専用です。すべてのgoldenの変更をレビューしましょう。