writing-tests

テストの作成

要求された動作を証明し、その動作が壊れた場合に失敗するテストを作成します。ユーザーが指定した範囲と、リポジトリの実際の契約に従ってください。このスキルは、実装、外部への操作、受け入れ基準の変更を許可するものではありません。

手順

1. テストを書く前に、リポジトリのテストランナー、固定されたラッパー、設定、近接するテスト、CI コマンドを確認します。対象を絞った実行コマンドと、全テストスイートの実行コマンドの両方を把握します。グローバルなデフォルトではなく、プロジェクトのツールを使います。追跡対象のスクリプトは移植可能な状態に保ち、個人用ラッパーを使う場合は外側の呼び出しにのみ適用します。
2. ユーザーの要件、実装された動作、引き継ぎ時に示すことを意図した内容からテストケースを導きます。各受け入れ基準に対し、あり得る誤った実装で失敗する、判別力のあるケースを割り当てます。テスト名は観測可能な動作を示すものにし、1 つのテストでは 1 つの動作のみを扱います。検証対象の特性に対して、意図的に厳しいフィクスチャを用意します。
3. 到達可能なテスト用シームがあるバグ修正では、再現テストを書き、意図どおり失敗することを確認してから、最小限の修正を加えて成功を確認します。実際のトリガーに到達できない場合は、test-completion.md のシーム不足に関するルールに従います。新機能では、選択したテスト方針に従って、垂直スライスで進めます。デフォルトはテスト後方式（小さな実装スライスを 1 つ行い、その後にテストを追加）です。テスト先行方式を明示的に選んだ場合は、テストを 1 つ書き、それを通す最小限の実装を行います。スライスごとに繰り返します。最初にすべてのテストを書き、その後ですべてを実装する水平スライスは、想定上の動作に対するテストを生むアンチパターンです。成功した後にリファクタリングします。実装を通すために、仕様、アサーション、フィクスチャ、スナップショット、期待値を変更してはいけません。
4. 実際の内部オブジェクト、実際の一時ファイル、実際のテスト用データベースを優先します。モックは外部との境界でのみ、所有するアダプターの最終段階に限って使用します。フレームワークが推奨する場合は、フレームワーク管理のフェイクを使用できます。モックを使う前に、実際の契約と副作用を確認します。
5. プライベートな構造、モックの呼び出し、フレームワークの動作ではなく、利用者から見える結果をアサートします。関連する境界条件、無効な入力、並行処理、失敗時のケースを含めます。エラー処理でエラーを捕捉、記録、置換、またはロールバックする場合は、エラーが確認できることに加え、観測可能な結果もアサートします。
6. 実行ごとに一意な、許容されない違反を使って、不在や分離に関するアサーションを証明し、その特定のアサーションが失敗することを確認します。評価の前に、制御用の変更が実際に適用され、ビルドが完了したことを確認します。制御用の変更を取り除き、成果物を元に戻して、成功を確認します。
7. 編集中は範囲を絞ったチェックを実行し、引き継ぎ前に該当するすべてのチェックを実行します。成功数と実行数を確認します。テストスイートが空、またはスキップされている場合、それは肯定的な証拠ではありません。

必要な詳細を選ぶ

• ケース、フィクスチャの形、モックの境界、単体テスト／統合テスト／E2E テストのバランスを選ぶ場合は、test-design.md を読んでください。
• バグ再現テスト、ミューテーション制御、または何かが起きてはならないことを検証する場合は、regression-proof.md を読んでください。
• 生成されたテストのレビュー、スナップショットの変更、非同期のタイミングのテスト、またはモックが振る舞いの代わりになっている場合は、test-smells.md と、該当する anti-patterns-extended.md の修正手順を読んでください。既存のテストが回帰を検出するか監査するには、ia-test-audit を使用してください。
• 弱い集約、空虚なアサーション、競合状態の再現、または対象に到達しない可能性のある制御については、oracle-smells.md を読んでください。該当する失敗パターンについて、より詳しいカタログを参照できます。
• コンテナーの状態、サンドボックス化、タイムアウト、環境の移設、プロセス／ストリームの分離については、isolation-and-sandbox-traps.md を読んでください。
• ラッパー、フィルター、適合性オラクル、スキップ条件、誤解を招く成功サマリーについては、false-pass-oracle-traps.md を読んでください。
• バイト単位の等価性や生成コーパスが契約となる場合は、generated-corpus-techniques.md を読んでください。値の形状やネストの違いを含め、独立した実装と比較してください。
• 行き詰まった場合、テストのスキップを検討している場合、またはテスト作業の引き継ぎをまとめる場合は、test-completion.md を読んでください。必要なテストに反対する理由を述べる前に、rationalization-table.md を読んでください。

検証と報告

公開されている振る舞いとエッジパス、テスト間の独立性、レビュー済みの期待値変更、主張する各機能を検証してください。ガードを取り除く、分岐を反転させる、または副作用を削除することを想定し、テストがそれを検出することを確認してください。頻繁に実行できる、十分に高速な単体テストスイートを優先してください（30 秒未満）。

テストで確認した内容、実際の結果、失敗、未実施事項を報告してください。フィクスチャと実際の動作確認を区別してください。フレームワークの規約には、該当する PHP/Laravel または React/TypeScript のスキルを使用してください。この汎用スキルは、それらに取って代わるものではありません。