テストの緑を信用しない — mock の空通しと偽陰性を疑い、実装を壊して落ちるかで検証する
テスト
設計判断
モック
原則
テストが通ったこと自体を品質の証拠にしない。mock の固定戻り値・状態共有・エラー握りつぶしは「分岐を通したつもりで通っていない」偽陰性(空通し)を生む。最適化するのは「実装を意図的に壊したら落ちるテスト」、避けるのは「mock の戻り値をそのままアサートして分岐の入口が固定されたままのテスト」。
判断基準
- 分解・プランニングを担う依存を、入力やカーソルに関係なく固定の小さな結果を返す mock にすると、分割・再開・集計のロジックがまるごと未検証で緑になる。mock の戻り値は入力規模を反映させ、境界(最低2チャンク・途中再開)を通す。
- トランザクション抽象を mock するときは、コールバックのエラーを伝播させる版を必ず用意する。常に成功を返す版だけだと内部の失敗分岐が握りつぶされ、異常系が偽陰性になる。
- ケース単位でなくメソッド単位で setup が走るスイートでは、回数指定のない成功 mock が後続の異常系に残って素通りさせる。衝突する異常系は分離するか、回数指定で使い回しを防ぐ。
- 埋まらない防御分岐は「真に到達不能」「テスト未追加」「到達すると壊れる(実バグ)」に分類する。三つ目はテストのために本番を歪めず、修正してからテストを足す。
気づき方 書いたアサーションに対し「実装をこう壊したら落ちるか」を1ケースずつ想像する。異常系で期待したエラーが nil になる・意図せず通る場合は、先行 mock の残留やエラー握りつぶしを疑う。独立した敵対的レビューを別に走らせると空通しを検出しやすい。
検証 カバレッジの数字でなく、各分岐について「壊して落ちるか」を確認する。落ちない分岐は通っていない。
根拠(synthesize 元)
- 557 チャンク処理・進捗再開の単体テストは入力分解 mock を固定値にしてはいけない
- 510 トランザクションモックのテストヘルパーはコールバックのエラーを伝播させる版を必ず用意する
- 526 testify suite はサブテスト間で mock 状態を共有する — エラー系は分離する
- 528 カバレッジで埋まらない防御分岐は「到達不能」と「壊れるから書けない」を区別する