ハーネスエンジニアリングのプラクティス P7. 負の検証 —— リグレッションとブラスト半径のゲート 🎯 ポイント エージェントは「自分の変更が動く」を最適化し、「他を壊していない」を過小評価します。正の検証だけでは流出欠陥は止まりません。 📝 概要 完了ゲートに、既存テストスイート全体の実行に加えて「触れたシンボルを誰がimportしているか」というブラスト半径チェックを組み込みます。自分のコードが動くかだけでなく、他の箇所を壊していないかを検証するのが負の検証です。 🔍 解説 エージェントは自然と「自分の変更に関連するテストが通る」ことに集中します。しかし、変更の影響は変更した箇所だけに留まりません。関数のシグネチャを変えれば呼び出し元が壊れ、共有モジュールの挙動を変えれば依存先すべてに影響します。負の検証とは「壊したものがないこと」を明示的に検証する仕組みです。変更したシンボルのimport元を特定し、それらのテストも実行する。影響範囲の可視化とそのテスト実行を完了ゲートに組み込むことで、流出欠陥を構造的に防ぎます。 🛠 実践方法 ・変更したシンボルのimport元を静的解析（import解析・コールグラフ）で自動特定するツールを完了ゲートに組み込みます ・特定された依存先のテストを自動的に実行対象に追加し、既存テストスイートと併せて実行します ・変更のブラスト半径（影響ファイル数・影響モジュール数）を差分と一緒に可視化し、レビュアーにも提示します ・カバレッジ情報と静的解析を組み合わせ、テストが不足している影響範囲を特定してフラグを立てます 💼 ユースケース ・issue-to-PRエージェントで、共有ユーティリティの変更時に全依存先のテストを自動実行する場面 ・マイグレーションエージェントで、APIシグネチャ変更の影響範囲を全て検証する場面 ・レガシーコード改修で、変更の波及先を特性評価テストでカバーする場面 ⚠ 落とし穴 ブラスト半径チェックを網羅的にやりすぎると、モノレポ全体のテスト実行になり非現実的です。影響範囲の特定には静的解析（import解析・コールグラフ）と動的解析（カバレッジ情報）の組み合わせが効果的です。また、負の検証が存在するからといって正の検証を軽視してよいわけではありません。両方が必要です。 #HarnessEngineering# #QualityAssurance#