この章の答え
変更に近いテストから始め、失敗の意味を確認して検証範囲を広げる。
コンパイルが通っただけでは、期待した動きになったかは分かりません。一方、すべてのテストを何度も回せばよいわけでもありません。変更した責務に合った観察点を選ぶのが出発点です。
01|図でつかむ
失敗は調査の入口。テストの数より、何を確かめたかを説明する。
02|3つのポイントで理解する
1. 単体・統合・スナップショットを使い分ける
関数の入出力、部品間の連携、描画結果では、適したテストの形が違います。変更が影響する境界を決めてから、近くの既存テストを読みます。
2. 失敗の理由を先に読む
実装の不具合なのか、期待値を更新すべき仕様変更なのかを区別します。スナップショットの差分は、承認すれば正しくなるわけではありません。表示内容や順序を確認します。
3. 検証を一段ずつ広げる
関連するテストが通ったら、必要に応じて crate 単位の確認へ進みます。使用したコマンド、対象範囲、失敗やスキップを記録し、実際に確かめた範囲を明確にします。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
just test -p codex-tui
# スナップショットの差分を確認
cargo insta pending-snapshots -p codex-tui
テスト用ツールはリポジトリの手順に従って用意します。ここに載せたコマンドは学習用で、この編集作業で Codex 本体のテストを実行したという記録ではありません。
読む入口: justfile 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
変更候補に近いテストを一つ読み、Arrange・Act・Assert に相当する箇所へ印を付けます。
04|30秒で復習
- 期待する振る舞いからテストを選ぶ。
- スナップショットは差分を読んで判断する。
- 成功だけでなく対象と実行件数を記録する。