テストが通ったこと自体を品質の証拠にしない。mock の固定戻り値・状態共有・エラー握りつぶしは「分岐を通したつもりで通っていない」偽陰性（空通し）を生む。最適化するのは「実装を意図的に壊したら落ちるテスト」、避けるのは「mock の戻り値をそのままアサートして分岐の入口が固定されたままのテスト」。

判断基準

• 分解・プランニングを担う依存を、入力やカーソルに関係なく固定の小さな結果を返す mock にすると、分割・再開・集計のロジックがまるごと未検証で緑になる。mock の戻り値は入力規模を反映させ、境界（最低2チャンク・途中再開）を通す。
• トランザクション抽象を mock するときは、コールバックのエラーを伝播させる版を必ず用意する。常に成功を返す版だけだと内部の失敗分岐が握りつぶされ、異常系が偽陰性になる。
• ケース単位でなくメソッド単位で setup が走るスイートでは、回数指定のない成功 mock が後続の異常系に残って素通りさせる。衝突する異常系は分離するか、回数指定で使い回しを防ぐ。
• 埋まらない防御分岐は「真に到達不能」「テスト未追加」「到達すると壊れる（実バグ）」に分類する。三つ目はテストのために本番を歪めず、修正してからテストを足す。

気づき方 書いたアサーションに対し「実装をこう壊したら落ちるか」を1ケースずつ想像する。異常系で期待したエラーが nil になる・意図せず通る場合は、先行 mock の残留やエラー握りつぶしを疑う。独立した敵対的レビューを別に走らせると空通しを検出しやすい。

検証 カバレッジの数字でなく、各分岐について「壊して落ちるか」を確認する。落ちない分岐は通っていない。

根拠（synthesize 元）

• 557 チャンク処理・進捗再開の単体テストは入力分解 mock を固定値にしてはいけない
• 510 トランザクションモックのテストヘルパーはコールバックのエラーを伝播させる版を必ず用意する
• 526 testify suite はサブテスト間で mock 状態を共有する — エラー系は分離する
• 528 カバレッジで埋まらない防御分岐は「到達不能」と「壊れるから書けない」を区別する