test-value-evidence

テスト値の証拠

テストに合格しても、関連する誤った動作を検出できなければ、ほとんど証明にはなりません。 リポジトリ全体ではなく、変更された契約と、それに直接関連するテストを評価してください。 リポジトリの指示、固定されたツールチェーン、テストコマンド、アサーションの規約、実行権限を確認し、それに従ってください。 このスキルは、読み取り専用レビューでの編集、信頼できないコードの実行、ワークフローのディスパッチ、公開、または別のセッションのチェックアウトへのアクセスを許可するものではありません。

入力と境界

対象として指定された差分またはリビジョン、本番コードのエントリーポイント、テスト、フィクスチャ、利用可能な実行成果物を確認してください。 変更箇所を特定できない場合は、ワークスペースを評価するのではなく、スコープが不足していることを報告してください。 変更のない既存テストで十分な場合もあります。ソースのみの差分だからといって、テストされていないとは限りません。

一般的な既存テストスイートの見落としには test-gap-analysis、テストごとのキュレーションされた準備状況や品質の評価には grade-tests、ミューテーションキャンペーンには既存のリポジトリのミューテーションツールを使用してください。 2つ目のミューテーションエンジンを起動したり、すべての変更についてフルスイートのミューテーションテストを必須にしたりしないでください。 このスキルは単独で完結します。隣接するスキルは任意の参照先であり、必須の依存関係ではありません。

ワークフロー

1. 契約をテスト対象のリビジョンに結び付ける。 PR の場合はマージベースと正確な head SHA を記録してください。 コミットの場合は選択した親とコミットを記録し、マージコミットの場合は親を明示してください。 未コミットの変更の場合は、ベース SHA と、関連する未追跡ファイルを含む、保存したパッチやハッシュなど再現可能なパッチ識別情報を記録してください。架空のコミット済みリビジョンとして扱ってはいけません。 関連するソース、テスト、ヘルパー、設定、またはパッケージに変更が加わった場合、証拠は再検証するまで無効です。

   動作の変更ごとに、次の対応関係を明らかにしてください。 要件 -> 入力／シーケンス -> 期待される公開結果 -> 本番コードのエントリーポイント -> テスト名／データケース -> 識別可能なアサーション 期待される結果は、実装やテストの現在値ではなく、要件またはサポート対象の API／プロトコルの仕様から独立して導き出してください。 ビルド／パッケージ／設定の動作、削除または名前変更されたコード、削除されたテスト、出荷先の利用側も確認してください。 肯定、否定、境界、互換性、キャンセル、クリーンアップ、複数モジュールのケースは、変更された契約に関連する場合にのみ含めてください。

   変更対象コンポーネントのモック、自己比較、または同じ本番アルゴリズムで計算した期待値は、独立した判定基準にはなりません。

2. 意味のある反実仮想を選ぶ。

   変更	反実仮想	必須の観測結果
   バグ修正	回帰テストを残したまま、修正前の実際の欠陥を復元します。	テストがその欠陥で失敗し、修正後は合格します。
   新機能	ビルドに必要な API の形状とセットアップを維持しつつ、動作を無効化／削除するか、壊します。	アサーションが動作の欠如／誤りを検出し、機能追加後は合格します。
   強化／テストのみのカバレッジ	妥当な誤った公開結果を1つ導入します。	強化されたテストがそれを検出し、変更前の製品は合格します。
   動作を保つリファクタリング	維持された契約を変更前後で比較し、必要に応じて関連する障害も試します。	契約維持のテストが両方のリビジョンで合格します。変更前の合格は想定どおりです。
   ドキュメント／生成メタデータのみ	実行可能な契約が変更されたかを確認します。	実行可能な契約が変わっていないと具体的な理由を示せる場合に限り、該当なしとします。生成物やビルドメタデータが動作を変える場合もあります。

   修正の場合は、同じ回帰テスト、セットアップ、依存関係、入力を使用して、実際の修正前の実装を試すことを優先してください。 新しい API のためにこの組み合わせではコンパイルできない場合は、head バージョン内で欠陥のある動作だけを復元してください。 これはベースリビジョンでの実行ではなく、対象を絞った反実仮想と呼んでください。 意図的に失敗させるためにアサーションを変更してはいけません。 機能について、シンボルが見つからないというコンパイラーエラーは、動作の証明にはなりません。 ビルド可能な no-op、登録の無効化、古い分岐、または誤った出力を選んでください。 コンパイラー／アナライザーの診断が有効な動作の証拠となるのは、実行される ハーネスがその診断そのもの、または診断が出ないことを検証する場合に限られます。

   ありそうな小さな不具合を優先してください。古い境界に戻す、必須の 出力を省く、コールバックをスキップする、オプションを無視する、または誤った値を 返す、といったものです。同等のミューテーションではギャップを証明できません。クラッシュ、 タイムアウト、例外が意図された契約上のシグナルであり、診断によってセットアップ、 検出、断続的な失敗、またはインフラストラクチャではなく不具合に原因があると 特定された場合に限り、証拠として扱えます。

3. 許可された場合に限り、対になる実行を行います。 実装作業では通常、 実行が必要ですが、読み取り専用／助言のみのレビューでは通常、調査のみが必要です。 レビューの依頼だけでは、ソースの編集やビルド／テストの許可にはなりません。 特権認証情報を使って、信頼できないコードを実行してはいけません。

   実装／検証が許可された環境では、次の手順に従います。

   • 自分が所有する隔離されたチェックアウトまたは実験用ディレクトリを使用します。 ユーザーの未コミットファイルや、他のセッション／メインのチェックアウトを 保護します。並行プロセスや共有出力／リソースを事前に確認し、無関係な プロセスを終了させないでください。
   • 正しい実装に対して、関連する最小限のテストだけを実行します。 指定されたテストとデータケースが実際に実行され、成功することを確認します。
   • 隔離された実験環境で、選んだ不具合のある動作だけを適用します。 同じテスト、アサーション、データ、依存関係、該当するランタイム構成で 再ビルドして再実行します。指定された失敗、アサーション、期待値／実際の 観測結果、プロセスの終了状態、診断を記録します。
   • 正しい実装に戻し、再ビルドして再実行し、再び成功することを確認します。 保護対象のソース／テストのバイト列を検証し、自分が所有する一時リソースだけを 削除します。反実仮想のパッチを製品に含めてはいけません。

   対になる実行では、古いビルド／テスト出力や、もう一方のバリアントの実効キャッシュを 再利用してはいけません。出力／キャッシュを分離するか、自分が所有する出力だけを クリーンアップして再ビルドします。--no-build や、ランナーが成功終了したことだけに 頼ってはいけません。各実行で、選択／実行／成功／失敗／スキップの件数を記録します。 ランナーが件数を表示しない場合は、作り上げずに不明と記載します。 選択／実行数がゼロの場合、スキップ、ツールの不足、認証、セットアップ／ビルド、 無関係な失敗、原因を特定できないタイミング由来の断続的な失敗がある場合は、 証明は未検証のままです。

   コンポーネント間／受け入れ動作については、まず生成側と消費側の契約を特定します。 該当する場合は、所有権、ライフサイクル、ハンドシェイクの有無、終了の意味、 フォールバック、互換性、キャンセル、複数モジュールの集約を確認します。 実際に出荷するバイナリ／パッケージ／拡張機能とリリースブランチを正確に記録します。 各バリアントを再ビルド／再パッケージし、実効パッケージキャッシュを分離し、 実際に出荷する消費側がどのバリアントを読み込んだかを証明してから、 代表的な複合コマンドを実行します。ユニットテストのモックや、ソース互換の コンパイルだけでは、出荷時の構成の検証に代わることはできません。該当する 通常、抑制、一部のみの動作、レガシー／非互換、キャンセル、ゼロ以外の終了コード、 結果ゼロ、フォールバック、複数モジュールの各経路を検証します。ロールアウト／ 保守の責任者を明確にします。機能フラグがあっても、証拠に求められる水準は 下がりません。

   読み取り専用／助言のみのモードでは、別途許可されていない限り、編集や実行をせずに 両方のリビジョン、セットアップ／ヘルパー、入力、アサーションを追跡します。 結論は静的な予測と表記し、実行による証明とは呼びません。既存の成果物が証拠として 有効なのは、リビジョン／パッチ、読み込まれたバリアント、選択数、件数、失敗の 原因特定が一致する場合に限られます。CI の成功や作者の主張だけでは、 レッド・グリーンの証拠になりません。アクセスできないものや不足しているものを 明記してください。

4. 得られた証拠のみを報告します。 引き継ぎ資料、または許可されたレビュー／説明に、簡潔なテスト値の証拠セクションを設けます。ベース／親とヘッドの SHA、またはテスト対象のパッチ識別情報を記載します。変更された契約ごとに 1 行とし、同じ契約を保護するテストをまとめ、評価していないグループを明示します。

   契約／テストケース	反実仮想	振る舞いがない場合	正しい実装	証拠／不足
   境界の不具合／指定ケース	古い比較を復元する；パッチ識別情報	実行済み：アサーション失敗	実行済み：成功	コマンド、終了コード、期待値／実際の値、件数、成果物
   新しい出力／指定ケース	出力書き込みをスキップする	静的評価：失敗を予測	未実行	ソース／アサーションの場所；対応する実行が未実施

   実行済み：検出、実行済み：生存、静的評価：検出を予測、静的評価：生存を予測、未検証、同等、該当なしを正確に使い分けます。赤／緑のいずれかの証拠が欠けている場合、または選定が不完全な場合、対応する証明は未検証のままです。実行済み：生存と報告するのは、実行済みかつ同等ではない欠陥についてのみです。同等の変更は不足として数えません。リファクタリングでの動作維持を確認するテストは有効な証拠であり、赤になる欠陥がないことを理由に不足とはしません。

   正確なコマンドと終了コード、ツールチェーン／フレームワーク／構成、リビジョンと反実仮想パッチの識別情報、実行ごとの件数、関連する成果物のパスを記載します。今回実行したことと、既存の成果物で確認したことを区別します。静的予測を測定済みのミューテーション件数／スコアと決して合算しません。最終 PR ヘッドの証拠だけでは、すべての中間コミットを証明できません。指定されたコミットは、その親に対して個別に評価します。

   証拠の不足が、直ちに欠陥の立証やインラインレビューコメントにつながるわけではありません。公開は呼び出し元の既存の承認ゲートに従います。レポートの保管だけを目的に、または指示によってフック、CI、公開が強制されると主張するために、新たな GitHub オブジェクトを作成しないでください。

検証

• 証拠によって、変更内容、独立したオラクル、テスト／データケース、意味のあるビルド可能な反実仮想が特定されています。
• バグ修正の証明では、実際の旧不具合で失敗し、修正によって成功しています。機能の証明では、シンボルの欠落ではなく、振る舞いの欠落または誤りを検出しています。
• 実行済みの主張には、帰属を確認できる結果、コマンド／終了コード、件数、および対応する成果物／利用者の来歴が含まれています。入手できない詳細は明示されています。
• 静的予測、生存、同等性、動作維持、証拠不足が、それぞれ区別されています。既存テストは、冗長なテストを追加せずに適切に評価されています。
• スコープ、読み取り専用の制約、クリーンなバリアント出力、並列実行の安全性、所有リソースのクリーンアップが維持されています。