behavioral-testinglisted

# Write Meaningful Tests ## 目的 AIがテストコードを書く時に、数や網羅率ではなく、退行を検出し、リファクタリングを妨げず、保守しやすいテストを作る。テストは資産ではなく保守コストを持つ負債でもあるため、価値がコストを上回る場合だけ追加する。 このスキルでは、単体テストを「1単位の振る舞いを、速く、他のテストから隔離して検証するテスト」と捉える。焦点はクラスやメソッドではなく、観察可能な振る舞いである。 ## 最初に止まる条件 次の条件に当てはまる場合は、テスト実装に入る前に質問するか、characterization test に限定するか、作業を止める。 - 期待値の根拠が現在の実装しかない。 - 仕様、issue、PRD、公開API契約、バグ再現条件、既存の明示的期待値のどれも見つからない。 - 境界条件、丸め、時刻の包含/排他などの仕様が未確定なのに、AIが期待値を補う必要がある。 - private method や内部呼び出ししか観察点がない。 - 既存のテスト規約、fixture/factory、実行コマンド、外部依存の扱いを確認していない。 - 外部サービスへ実通信しないと成立しない。 - テストを通すためだけにプロダクションコードを汚染しそうである。 ## 判断フロー 1. 仕様オラクルを特定する。 仕様、issue、PRD、公開API契約、ユーザー報告、バグ再現手順、既存の明示的な期待値を探す。実装の分岐や定数を丸写しして期待値を作らない。 2. 観察可能な振る舞いを1つ選ぶ。 クライアントが達成したい結果、公開APIの戻り値、公開状態、外部から観察できる��作用に絞る。 3. コードを分類する。 ドメイン/アルゴリズムは単体テスト、コントローラは統合テスト、取るに足らないコードは原則テストしない。複雑さと協力者が両方多いコードは、先に責務分離を提案する。 4. 依存を分類する。 管理下依存は実物で状態を確認する。管理下にないプロセス外依存だけを、所有する境界アダプタのモックまたはスパイに置き換える。システム内コミュニケーションは検証しない。 5. テスト手法を選ぶ。 出力値ベースを最優先する。必要に応じて状態ベース、ドメインイベント、統合テストでの境界スパイを選ぶ。コミュニケーションベースは外部から観察可能な境界通信に限定する。 6. 既存規約に合わせて実装する。 既存のテストランナー、命名、fixture、factory、assertion library、DB初期化、cleanup、CIコマンドに合わせる。 7. 最小の検証コマンドを実行する。 追加・変更したテストを最小範囲で実行し、必要なら関連テストまで広げる。 ## 実装前チェック テストを書く前に、短くてもよいので次を自分の中で埋める。 ```text 仕様根拠: 観察する振る舞い: テスト対象分類: テストレベル: 依存の扱い: 使う既存fixture/factory: 時刻/乱数/並行性/外部I/Oの扱い: 実行コマンド: ``` この表を埋められない場合、テストを書くよりも先に不足情報を調べる。調べても埋まらない場合は、ユーザーに確認する。 ## モックのルール - 単体テストで安易にモックを作らない。設計が悪くてテストしづらい箇所をモックで隠さない。 - スタブは入力を供給するために使う。スタブとのやり取りは検証しない。 - モック/スパイは外向きのコミュニケ