Claude Codeが書いたテストを読む：実装の写しではなく失敗を検出する

期待値を実装から作らない

変換処理の期待値を、同じ変換関数で作ると循環します。仕様から決めた入力と期待結果、既知の境界例、保存済みの正式なデータなど、実装から独立した根拠を使います。

画面テストでは、単に部品が存在することと、利用者が目的を達成できることを分けます。送信ボタンがあるだけでは、未入力のエラーや失敗後の復帰は確認できません。

変更に関わる失敗を選ぶ

入力検証を変えたなら、正常な値だけでなく、空、境界、異常な型、別の利用者の対象などを考えます。すべての組合せを増やすのではなく、今回壊れ得る業務上の失敗を選びます。

反対に、見た目の小さな文言変更へ大量の同じテストを足す必要はありません。必要な回帰を残し、テストの維持費と得られる証拠の関係を意識します。

テスト結果をソースと結び付ける

以前通った結果が今も有効かは、実際の入力と対象コードが変わったかによります。変更後に影響する確認を行い、別の版の成功を現在の成功として報告しないようにします。ブラウザーの観察と、ソースを使った検証も区別します。

壊したら落ちるかという問いを持つ

そのテストが通ることだけでなく、どの誤った実装なら失敗するかを考えます。たとえば常に成功を返す処理、境界の値だけ間違える処理、別の利用者の対象を許す処理です。実際に本番の守りを壊す必要はありませんが、テストの期待値がこれらを区別できるかを読むことで、単に現在の実装をなぞった確認を発見しやすくなります。

外部サービスを置き換えたテストでは、その置き換えが何を省いているかも明記します。常に成功する代用品なら、タイムアウトや不整合を検証したことにはなりません。画面を表示しただけなら、キーボード操作や端末上の見え方を確認したことにもなりません。証拠の範囲を正直に記録し、今回の変更に必要な別の確認へつなげることが、数を増やすより重要です。

具体例で考える

架空の価格表示を検証するテストが、表示側と同じ計算関数から期待値を作っています。

弱い確認：同じ関数の結果同士を比較。
改善：仕様から計算した小さな例と比較。
追加：端数、0件、無効な数量の扱いを確認。

何度も同じ結果になることは、仕様に合う証拠とは限りません。外から決めた期待値があることで、計算式の誤りを検出できるようになります。

確認課題と合格の目安

一つのテストを選び、期待値の出所と、検出できる具体的な誤実装を書いてください。

• 期待値が実装そのものへ依存していない。
• 今回影響する異常系を確認している。
• 実行したソースの版が分かる。