この章の答え
バグの症状が再発したら失敗するテストを、適切な境界に置く。
「ある関数が呼ばれた」だけを確かめるテストは、コードの整理で壊れやすくなります。待機入力の問題なら、その入力が次の処理へ渡ったかという結果を捉えるほうが、守りたい意味が明確になります。
01|図でつかむ
同じテストが修正前に失敗し、修正後に通ることを確かめる。
02|3つのポイントで理解する
1. テストの境界を決める
入力欄の見た目を守りたいのか、Core へ送る操作を守りたいのかを明確にします。キューの進行が問題なら、次の要求が観察できる境界を選びます。
2. Arrange を最小にする
必要な待機入力や失敗条件だけを用意します。内部フィールドを大量に直接書き換えると、現実の操作ではできない状態を作る危険が増えます。
3. 結果と副作用を検証する
期待する入力が送られたことに加え、二重送信や順序の崩れがないかを確認します。無関係な描画文字列に依存しすぎないよう、守る契約を絞ります。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "backtrack_branch_failure|next_user_turn_op" codex-rs
読む入口: codex-rs/tui/src/app_backtrack.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
原稿の backtrack の例を、準備・操作・期待結果の三文へ書き換えます。テスト名が現在存在するかも実行前に検索します。
04|30秒で復習
- 関数の呼び方より観察可能な結果を守る。
- 準備する状態を最小にする。
- RED と GREEN が同じ問題を示すか確認する。