engram-testing-coverage

使用するタイミング

次の場合にこのスキルを使用します。

• 新しい動作を追加するとき
• バグを修正するとき
• 分岐が複雑なロジックをリファクタリングするとき

---

TDD のサイクル

1. 対象の動作に対する失敗するテストを書きます。
2. テストに合格する最小限のコードを実装します。
3. テストがすべて成功する状態を保ちながらリファクタリングします。
4. 完了する前に、エッジケースとエラー経路のテストを追加します。

---

カバレッジのルール

• 正常系、エラー経路、エッジケースをカバーします。
• 不安定な統合テストより、決定論的なテストを優先します。
• 分岐を自然に実行できない場合に限り、テスト用の接続箇所を追加します。
• 接続箇所を追加する場合も、実行時の動作は変更しません。

---

検証の責任範囲

検証は候補に関する証拠であり、CI は自動実行の場であって、ローカルでの対象を絞った検証の代わりにはなりません。

• 動作を変更した場合は、変更を提案する前に、対象を絞った回帰テストと、影響を受けるパッケージのテストをローカルで実行します。実行したコマンドと結果を報告します。
• 見落とした動作や分岐を探すのに役立つ場合は、対象を絞ったカバレッジを使用します。すべての PR で数値目標やモジュール全体のカバレッジを必須にする必要はありません。
• 候補を PR にプッシュした後は、GitHub CI がユニットテストスイート（go test ./...）、E2E テストスイート（go test -tags e2e ./internal/server/...）、リンター、および該当するプラットフォームチェックをすべて実行します。これらのチェックが実際に実行されるまでは、CI の検証結果を報告しないでください。
• PR がない場合、候補が未プッシュの場合、またはリスクを考慮して追加の検証が妥当な場合は、該当する追加チェックをローカルで実行します。実行できなかったチェックは、CI でカバーされたと主張せず、証拠がないものとして報告します。PR の CI で幅広いテストスイートが実行される場合は、通常、ローカルでの重複実行を避けてください。