test

テスト

名前の付いた動作について、テストを作成または強化します。既知のテストスイートを実行するだけの場合は、既存のテストをそのまま使ってください。このスキルを必須のラッパーとして使う必要はありません。実装を実行するだけでなく、受け入れ可能な結果と、起こり得る不具合を見分けられるテストが有用です。テストが成功したことは、呼び出し元が判断するための根拠であり、テスト作成者によるマージ承認ではありません。

モード

モード	使用する場面	結果
generate	既存の動作にテストが必要な場合	有用なテストと、対象を絞ったテスト結果またはスイートの結果
coverage	呼び出し元が網羅性の不足を見つける、または補うよう求めている場合	変更前後のカバレッジ、有用なテスト、残るリスク
tdd	新しい動作をテストファーストで開発する場合	実際に期待どおり失敗する RED、実装、成功する green、リファクタリング
strategy	呼び出し元がテスト設計だけを求めている場合	優先順位を付けたリスクと、既存のやり取りで提示するチェック案

既定では generate を使用します。モードとスコープはスキルのプロンプトで指定し、存在しない CLI フラグを作り出さないでください。カバレッジのしきい値は、呼び出し元またはリポジトリの指定に従います。

重要な制約

• 約束された効果をアサートします。 その動作が境界で約束する状態変更、外部呼び出し、または件数を確認します。保存されたレコードの形状自体が契約でない限り、プロダクトが提供する読み取り経路からレコードを読み戻してください。期待値は、実装自身の計算式やモックの応答ではなく、リテラル、具体例、仕様から正確に導きます。たとえば、50 に 20％の割引を適用する場合は、40 をアサートします。ステータスコード、返されたオブジェクト、または例外が発生しないことだけでは、動作の証明になりません。コードが空またはデフォルトの結果を返しても、このテストは成功してしまうでしょうか。拒否テストでは、同じ入力を別のガードが拒否する可能性があるため、そのテスト名が示すエラーをアサートします。
• 回帰テストは、修正前のコードで失敗するまで何も証明しません。 Mutation-kill proof を参照し、報告の原因となった呼び出し元、手順、または状態を通じて、修正前のコードで失敗することを示してください。変更した行だけで確認してはいけません。そこまで示せていない場合、証明の状態は「未提示」と報告してください。テストが成功しただけでは、まだ証明になりません。
• 受け入れられている観測可能な動作からテストケースを導きます。新しいケースを考案する前に、会話、bead、仕様、または既存の契約にある例を再利用してください。確立されたドメイン名を維持し、テスト名を変更して、境界づけられたコンテキストの用語を統一しないでください。
• リポジトリで使用しているフレームワークと実際のチェック手順に従います。意図しないタイミング、順序、共有状態への依存がテストに入り込まないようにしてください。
• 既存の正しい動作で最初から成功するテストにも意味があります。変更前のテスト未実施箇所を押さえるために活用し、意図しない結果が見つかった場合は、欠陥の疑いがあるものとして明記してください。RED を偽って報告したり、プロダクトの欠陥を正当化するために受け入れ条件を変更したりしてはいけません。
• 欠陥の修正がすでに許可されている場合は修正します。それ以外の場合は、再現方法と発見内容を報告してください。テストの削除や弱体化によって欠陥を覆い隠してはいけません。

オラクルの強さの階層

既知の場合は、正確な観測可能な値やエラーを優先します。契約を具体例より忠実に表す場合は、プロパティや不変条件を使います。差分による一致を使うには、独立して信頼できる参照が必要です。スモークチェックが証明するのは観測したことだけであり、それ単独では正確な動作を立証できません。要約やランキングのように正しさが意味に関わる場合、件数はあくまで代理指標です。証明の忠実度に従って評価してください。オラクルに重大な制約がある場合は、ワークシートや必須レポートを作成するのではなく、通常の引き継ぎで説明してください。

ミューテーションによる不具合検出の証明

重要な新しい動作チェックが、検出を目的とする不具合を実際に検出できることを確認します。修正前の真正な RED または再現例があれば、通常は十分です。回帰テストを修正後に作成した場合は、修正前のバージョンに対して実行するか（修正を分離したコピーで取り消します）、安全で対象を絞ったネガティブコントロールを使用します。オラクルへの実質的な疑念を解消できる場合に限ってミューテーションを行い、その後、元に戻して候補を検証します。表の行や新しいテストごとにミューテーション実験を要求しないでください。候補のコミットと未コミットの変更に、その編集だけを加えた状態であることを確認したコピーから得られた結果のみ、取り消しやミューテーションの結果として信頼します。HEAD から切り出したワークツリーには、修正やテストが含まれないことがあります。共有チェックアウトにはミューテーションを行わないでください。

ハーネスの健全性基準

ランナーが完了したこと、対象のテストが実際に実行されたこと、アサーションが約束された動作を確認していることを確認します。結果は出力内容ではなく、ランナーの終了ステータスに基づいて判断し、パイプを使う場合はそのステータスを保持します（pipefail）。make test | tail が報告するのは tail のステータスです。追跡対象ファイルを編集するチェックによって対象の状態が変わった場合は、その編集を報告します。クラッシュ、出力の途切れ、予期しないスキップや除外は、カバレッジの不足として報告します。ランナーのテスト検出や失敗報告に変更があった場合は、グリーンを信頼する前に、同じ経路でネガティブコントロールを実行します。変更自体が実際の実行の代わりとなるチェックの場合は、保護対象に照らしてそのコンテキストも適切であることを確認します（実際の実行の代わりとなるチェック）。変更されていない健全なランナーを、編集のたびに再検証する必要はありません。

ワークフロー

1. 受け入れ済みの例と、関連する公開インターフェースを読みます。小さな変更であれば、判別力のある例が1つあれば十分な場合もあります。受け入れ条件を否定し得るエラーケースと境界ケースを追加します。.feature ファイルは任意です。リポジトリですでにシナリオとテストのアノテーションを対応付けている場合は、それを維持し、リポジトリのシナリオカバレッジチェッカーを使用します。複数のレコード種別で異なるアクションをサポートする場合は、受け入れ済みのドメインルールから意味のある種別とアクションの組み合わせを導き、それぞれで約束された最終状態を確認します。成立しない組み合わせを作り上げたり、ある種別の結果を、別の種別でテストが成功したことから推測したりしないでください。テーブルテストで多くの組み合わせをカバーできます。セルごとに別の成果物やテストを用意する必要はありません。関連する未確認の組み合わせは unchecked に報告します。複数の種別をどちらも削除すべき場合、共通の削除コードを使うのは妥当です。一方、取り下げによって非アクティブな状態で保持すべきレコードを削除するなど、観測された最終状態が受け入れ済みの意味に反する場合は不具合です。
2. 対象のテストスイートと、絞り込んだベースラインを見つけます。不具合の場合は、コードを変更する前に、どのテストでその証明を担うか決めます。報告された処理の連鎖に到達する接合点がない場合は、より浅い代替テストを書きません（不具合の証明を配置する）。テストの選択が変わる場合に限り、Domain の基準を使用します。広範なカバレッジの測定は、coverage モードの場合、または既存のリポジトリ要件がある場合に限ります。
3. 安定したインターフェース、つまり呼び出し元が使うエントリーポイントを通じて、約束された結果を観測する最小限のテストを書きます。テスト専用のエクスポート、フラグ、フックを追加しないでください（時刻、乱数、外部境界の接合点は例外です）。ユニット内の協調要素をモックしないでください。動作を保った書き換えで壊れるテストをここで書く場合は、インターフェースまで移動します。既存のものは、書き換え候補として報告します。tdd モードでは、実装前にテストを実行し、期待される動作の欠落による失敗を確認してから実装し、グリーンを保ちながらリファクタリングします。テストは一度に1つずつ進め、次のケースは前のサイクルで分かったことをもとに選びます。
4. 編集中は対象を絞ったチェックを実行し、引き渡し前に関連する統合レシピを実行します。追加で広くチェックするのは、変更によるリスク、失敗、またはリポジトリのポリシーが理由となる場合に限ります。
5. 元の受け入れ済みの例と比較します。実装後に追加した新しいテストは補足にはなりますが、元の例の代わりにはなりません。

専門分野別の参考資料

対象に必要なガイダンスのみを読み込んでください。

• 公開されている互換性契約：conformance-harnesses
• パーサーと悪意のある入力：fuzzing
• スナップショット：golden artifacts と update strategy
• 不変条件：metamorphic testing
• サービス統合：real-service E2E
• 選定されたユーザージャーニー：exploratory QA
• 許可されたテストスイートの保守：suite audit
• 証明の配置、代替チェック、評価対象の出力：proof fidelity
• CLI/API の失敗シグナルと不確実な書き込み結果：error recovery
• タイミング、共有状態、または並行処理の失敗：difficult-failure experiments
• ワークロードのベースラインと候補の比較：subject performance

出力仕様

テストはリポジトリの言語に適した場所に配置してください。事実と制限事項は、既存の引き継ぎ資料に記載します。

tests:     <file::name> -> <behavior and exact values it asserts>
proof:     <each important new test> -> how it was shown to fail on its defect:
           pre-fix RED | reverted-fix run | negative control | not shown
commands:  <exact command> -> <result>
harness:   <runner completed; how many ran; skips or exclusions>
defects:   <discovered defect and reproducer, or none>
unchecked: <material behavior no test covers>

カバレッジなどのレポートは、依頼された場合、または宣言された利用者に必要な場合に限り、指定された保存先に保存してください。.agents/ への自動出力は行いません。事実に基づく成功結果は、呼び出し元がマージまたはレビューを判断する際の入力であり、テスト作成者を拘束する PASS ではありません。

例：Job の重複配信では、完了済みの結果が返され、外部への副作用が一度しか呼び出されないことをアサートします。こうしたアサーションのないカバレッジの増加では、その動作を証明できません。

このガイダンスでは、AgentOps が既に定めている受け入れ基準とエビデンスの境界を踏まえ、Matt Pocock のエンジニアリングスキルに基づく独自の例を使用しています。