test-value

テストの価値

保護する価値のある成果を、そのリスクに見合ったコストで守ります。テスト数、カバレッジ率、テストの成功は証拠であり、プロダクトに関する判断の代わりにはなりません。AI が実装とテストの両方を書く場合は、同じ誤った前提を共有していないか確認してください。

対象範囲を選ぶ

ユーザーが定めた既存の権限と運用上の境界を守ってください。

• 既存テストの監査： 依頼された範囲内で、コスト、誤検知、保護内容を調査します。監査の依頼は読み取り専用です。最適化の依頼では、範囲を限定した変更が認められます。audit.md を参照してください。
• 実装またはコミット前レビュー： 変更対象の動作と、それに影響するテストを調べます。テストを追加、調整、再利用、削除するか判断してください。コミット前のレビューは、それ自体ではコミットやプッシュの許可にはなりません。
• 失敗の診断： 失敗したチェックが何を保護しているかを特定し、プロダクトのリグレッション、古くなったアサーション、環境の問題、テストの不安定さを見分けます。範囲を限定した修正を求められた場合は、その範囲を守ってください。

自動レイアウトのスナップショット、共有マトリックス、ソースコードに対するアサーション、非同期の待機、テストダブル、ベンチマーク、カバレッジの不足を扱う場合は、decision-examples.md を参照してください。

正しさを判断する独立した根拠を確立する

ユーザー要件、公開された契約、互換性へのコミットメント、または実際の障害をもとに、何が維持されるべきかを説明します。現在の実装や、その実装が生成した出力だけでは、正しい期待値の根拠になりません。

追加または変更するテストについて、理由の説明または短い変更説明で、次の3つの問いに答えてください。

1. このテストで失敗する具体的な間違いは何ですか。それによってユーザーやメンテナーにどのような損失が生じますか？
2. 同等のリファクタリングや、より優れた正当な結果でも失敗しますか？実際に契約で定められている制約はどれですか？
3. この間違いをすでに検出する既存のテスト、型チェック、その他のチェックはありますか？追加の保護は、実行コストと保守コストに見合いますか？

観測可能な出力、状態、データの整合性、失敗時の動作を優先してください。プライベート関数のテスト、スナップショット、静的チェックも実際の境界を保護できます。その形式だけで価値が決まるわけではありません。

最小限かつ効果的なテスト判断を行う

根拠	判断
対処する価値のある失敗境界が明らかになった	その境界を検出できる最も低コストのレイヤーに回帰テストを追加し、必要な場合は実際の統合経路も維持します
既存のテストでその誤りがすでに失敗として検出される	別のフィクスチャ群を作るのではなく、そのテストを再利用または拡張します
テストが、契約で定められていない実装や自動生成される出力を固定している	明示的な制約を維持しながら、結果の特性、妥当な許容範囲、または境界を検証します
複数のテストが同じ実装経路を通じて同じ失敗を防いでいる	重複を統合または削除し、残す保護を明確にします
共通のルール表が複数のエントリーポイントで繰り返されている	共通ロジックを通じてルールセットを網羅し、各エントリーポイントの統合を検証します。ただし、相互作用がある組み合わせや独立した実装は維持します
コストの高いテストが固有のリスクを防いでいる	カバレッジを維持し、フィクスチャを改善するか、リスクに応じて実行対象を選びます
過去の契約が明示的に終了した、または機能が削除された	残存する利用者がいないか確認してから、不要になったテストを廃止します
保護の担当範囲や正しい期待値が不明確	失敗を減らすために推測するのではなく、テストを維持し、不足している根拠を明らかにします

編集のたびにテストを追加することが目的ではありません。単純な文言変更、機械的な編集、効果的なカバレッジですでに網羅されている変更では、新しいテストが不要な場合があります。ユーザーが製品上の制限の削除を承認した場合は、テストも更新してください。古いアサーションを理由に、承認された製品変更を拒むことはできません。

データの損失や破損、権限や信頼境界に関する失敗、約束された互換性、不可欠なアクセシビリティ上の失敗、リソースリーク、復旧の失敗に対する効果的な保護を維持してください。こうしたチェックを簡素化する場合も、保護が維持されることを示す根拠が必要です。一括スキップ、再試行、許容範囲の拡大、スナップショットの更新によって、回帰を隠してはいけません。製品上の約束や必須のリリースプラットフォームのゲートを変更する場合は、ユーザーが承認した範囲内でなければなりません。

テストの識別能力を確認する

テストを追加するたびに別のテストスイートを作成するのではなく、リスクに見合った根拠を用いてください。

• バグ修正： 可能であれば、回帰テストで元の失敗を再現し、修正後にテストが成功することを確認します。再現できない場合は、その不足を明記します。
• アサーションの緩和： 妥当な代替結果と、元の不適切な結果を試します。前者は成功し、後者は失敗する必要があります。影響の大きいエラーには一時的な障害の注入が役立つ場合がありますが、ミューテーションスコア自体を目的にしてはいけません。
• 統合または削除： 実際の呼び出し経路をたどり、残るテストで同じ誤りを検出できることを確かめます。名前が似ていること、ヘルパーを共有していること、行カバレッジが重なっていることだけでは、重複の根拠になりません。
• 共有フィクスチャ： 可変状態をリセットし、失敗を試みる間も分離とクリーンアップのアサーションを維持します。改善は、テストの実行順序や偶然のキャッシュヒットに依存してはいけません。

破壊的なプローブは一時コピーまたは管理されたフィクスチャで実行し、既存のユーザー変更を保持してください。環境を利用できない場合は、検証上の不足となります。シミュレーションによる根拠を、実際のブラウザー、オペレーティングシステム、または配布パッケージの代わりにしてはいけません。

フィードバックコストを管理する

プロジェクトで実際に使われているテストコマンド、CI の選択ルール、現在の変更内容を確認してから、リスクをカバーできる最小限のチェックを選びます。影響を受ける動作に応じて、統合テスト、ブラウザーテスト、プラットフォームテスト、または完全な検証が必要かどうかを判断します。

フィルター、テストの収集、スキップも含め、意図したテストが実際に実行されたことを確認します。関連するテストがないコマンドの成功は、その動作が検証された証拠にはなりません。影響を受けるテストがない変更では、テストが選択されなくても問題ない場合がありますが、終了コードがゼロだったことから推測するのではなく、その理由を確かめます。

リビジョンの識別情報、入力、環境、カバレッジが引き続き適用できる結果は再利用し、何を再利用したかを明示します。新たな変更、失敗、未解決のリスクによって証拠が無効になる場合は、検証を拡張するか、やり直します。診断のために失敗の範囲を絞り、完全なテストスイートを繰り返し起動するのは避けます。

速度向上を主張するのは、測定した場合に限ります。テストケースの時間、ファイルの処理時間、並列パイプラインのクリティカルパス、総計算時間を区別します。入れ子になったログの時間は正しく解釈します。親スイートの所要時間は、最後に実行された子の所要時間ではありません。測定値を比較する際は、実行環境、プラットフォーム、入力、キャッシュの状態、競合する処理を統一します。

利用から学ぶ

実際の利用を通じて、価値のある新しいテスト原則やこのガイダンスの欠陥が明らかになった場合は、実行中の環境の権限とユーザーの指示の範囲内で、このスキルをその場で改善してもかまいません。これは任意の保守作業であり、すべてのタスクで必須の手順ではありません。改善の範囲を適切に保ち、元のタスクを優先してください。

スキルを変更する前に、次の点を確認します。

• 根拠： もっともらしい標語ではなく、実際に観察された結果、失敗、または十分な裏付けのある反例があること。明確な事例が一つあれば限定的な修正を正当化できる場合がありますが、より広範な主張には、それに見合う根拠が必要です。
• 判断への影響： エージェントの判断がどう変わるのか、既存のガイダンスではなぜ十分でないのかを明確にします。
• 適用範囲： その原則が当てはまる条件と、意味のある例外や反例を明確にします。プロジェクト固有の慣例は、ここで普遍的な原則にせず、プロジェクトのガイダンスに記載します。

新たなルールを追加するより、既存の原則を改訂または統合することを優先します。複数の領域に関わる原則はこのエントリーポイントに、条件付きの例は適切なリファレンスに記載します。追加内容は英語にし、非公開のインシデント情報や一時的な測定値は記載せず、認可と保護の境界を維持します。教訓を得たからといって、リポジトリの変更、公開、または他のインストール環境への同期が広く許可されるわけではありません。

変更後のガイダンスに矛盾や不要な義務がないかを確認し、影響がある場合はリンクとメタデータも確認します。変更によって動作が変わる場合は、現実的な判断シナリオで検証します。スキルを利用できない、または読み取り専用の場合は、具体的な改善案を提示し、保存していないことを説明します。

スキルを更新した場合は、最終回答で必ずユーザーに伝えます。変更したファイルへのリンクを示し、追加または改訂した原則を要約し、その根拠や理由を説明します。保存した変更と提案を区別します。既存のガイダンスですでに教訓が説明されている場合は、更新する必要はありません。

報告して終了する

保護した動作、テストの変更とその理由、実行または再利用した証拠、スキップ、意図的なカバレッジ上のトレードオフを簡潔に報告します。時間の変化を報告するのは、比較可能な測定値がある場合に限ります。通常の開発では、追加のガバナンス報告、スコアリングシステム、CI ポリシーは必要ありません。

監査では、調査した候補を「変更済み」「維持」「証拠待ち」として記録します。価値の高い候補への対応が済み、残りの候補に根拠がない、または削減できるコストより対応コストのほうが大きい場合、その回の作業を終えてかまいません。目的は、削除を際限なく続けることでも、プロセスを増やし続けることでもありません。対象を絞った検証、完全なテストスイート、ビジュアル検証、プラットフォーム検証、リリース受け入れの各主張は、明確に区別します。