変更範囲に応じた検証

選択と再利用は別の問い

選択は この変更がどの確認に影響し得るか、再利用は 関連入力・条件のもとで過去の結果が今も有効か を問います。一方の妥当性だけで他方は証明できません。ビルドartifactの共有も、テスト結果を再利用できる証明ではありません。

基準はCI履歴を踏まえ、必要な検証が成功したrevisionから選びます。直前commitだけを機械的に比較すると、途中の失敗・未実行・共有設定の変更が残る場合があります。tested SHAと入力の識別子を記録します。revision一致はlive依存には十分でなく、関連入力が同等なら異なるrevision間でも再利用できるため必要条件でもありません。

実際の入力を特定する

対象コード、テスト本体、共通helper、間接依存、fixture・seed、設定、feature flag、関連環境変数、コマンドと引数、runtime、browser、toolchainを考えます。影響する入力を宣言し、全環境変数を無条件に含めたり証拠にsecretを露出したりしません。

外部依存は必要に応じて固定・隔離します。live API、registry、未固定依存、時刻依存の挙動はソース差分なしでも変化します。固定や同等性の説明ができなければ再実行します。定期再試験は外部変化を検知し、関連するソース・環境変更時にも範囲を定めて再検証します。

証拠を辿れるようにする

既存ツールの情報から入力・条件のfingerprint、元run、コマンド、環境、検証revisionを識別します。新規成功／同等性を確認した成功結果の再利用／未実行／失効・不明 を区別します。verification mapで受容リスクをProvenとしません。

導入時は代表的な共有コード・設定・間接依存変更で、選択範囲が広がりcacheが失効することを確認します。期間を限って従来の全件実行と比較する方法もありますが、恒久的な二重実行は一般義務ではありません。モデルが不完全なら安全側へ戻します。

時期は別の方針

定期実行への移動は検知の遅れを変えます。有効な再利用は同等条件での再計算を省きます。この2つを同じ保証維持の高速化として扱いません。実行ティアと一時的なredを許容する開発に沿い、マージ・リリース前の義務を明示します。取消・後続runへの置換は成功ではなく、まとめて検証しても未解決alertは残します。

検知自体を継続するかはテストのライフサイクルが扱います。本ページはツール非依存の条件を定義します。Nxの採用判断・実験は別件であり、ここでは未検証です。