diff --git a/builtins/en/facets/instructions/write-tests-first.md b/builtins/en/facets/instructions/write-tests-first.md index 4306077..7681e44 100644 --- a/builtins/en/facets/instructions/write-tests-first.md +++ b/builtins/en/facets/instructions/write-tests-first.md @@ -7,7 +7,11 @@ Refer only to files within the Report Directory shown in the Piece Context. Do n 1. Review the plan report and understand the planned behavior and interfaces 2. Examine existing code and tests to learn the project's test patterns 3. Write unit tests for the planned features -4. Write E2E tests if appropriate +4. Determine whether integration tests are needed and create them if so + - Does the data flow cross 3+ modules? + - Does a new status/state merge into an existing workflow? + - Does a new option propagate through a call chain to the endpoint? + - If any apply, create integration tests 5. Run the build (type check) to verify test code has no syntax errors **Test writing guidelines:** diff --git a/builtins/en/facets/policies/testing.md b/builtins/en/facets/policies/testing.md index ffe8c55..2df31f6 100644 --- a/builtins/en/facets/policies/testing.md +++ b/builtins/en/facets/policies/testing.md @@ -70,6 +70,17 @@ Test names describe expected behavior. Use the `should {expected behavior} when - Do not overuse E2E tests for what unit tests can cover - If new logic only has E2E tests, propose adding unit tests +### When Integration Tests Are Required + +Verify data flow coupling that unit tests alone cannot cover. + +| Condition | Verdict | +|-----------|---------| +| Data flow crossing 3+ modules | Integration test required | +| New status/state merging into an existing workflow | Integration test for the full transition flow required | +| New option propagating through a call chain to the endpoint | End-to-end chain coupling test required | +| All module-level unit tests pass | Unit tests alone are sufficient (when none of the above apply) | + ## Test Environment Isolation Tie test infrastructure configuration to test scenario parameters. Hardcoded assumptions break under different scenarios. diff --git a/builtins/ja/facets/instructions/write-tests-first.md b/builtins/ja/facets/instructions/write-tests-first.md index 1c3de1f..f8a7c3a 100644 --- a/builtins/ja/facets/instructions/write-tests-first.md +++ b/builtins/ja/facets/instructions/write-tests-first.md @@ -7,7 +7,11 @@ Piece Contextに示されたReport Directory内のファイルのみ参照して 1. 計画レポートを確認し、実装予定の振る舞いとインターフェースを理解する 2. 対象モジュールの既存コードと既存テストを確認し、テストパターンを把握する 3. 計画された機能に対する単体テストを作成する -4. 必要に応じてE2Eテストも作成する +4. インテグレーションテストの要否を判断し、必要なら作成する + - 3つ以上のモジュールを横断するデータフローがあるか？ + - 新しいステータス／状態が既存ワークフローに合流するか？ + - 新しいオプションが呼び出しチェーンを通じて末端まで伝搬するか？ + - いずれかに該当すればインテグレーションテストを作成する 5. ビルド（型チェック）を実行し、テストコードに構文エラーがないことを確認する **テスト作成の方針:** diff --git a/builtins/ja/facets/policies/testing.md b/builtins/ja/facets/policies/testing.md index 0a3081d..59f1eeb 100644 --- a/builtins/ja/facets/policies/testing.md +++ b/builtins/ja/facets/policies/testing.md @@ -70,6 +70,17 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async - ユニットテストでカバーできるものにE2Eテストを使いすぎない - 新しいロジックにE2Eテストしかない場合、ユニットテストの追加を提案する +### インテグレーションテストが必須な場面 + +ユニットテストだけでは検証できないデータフローの結合を検証する。 + +| 条件 | 判定 | +|------|------| +| 3つ以上のモジュールを横断するデータフロー | インテグレーションテスト必須 | +| 新しいステータス／状態が既存のワークフローに合流する | 遷移フロー全体のインテグレーションテスト必須 | +| 新しいオプションが呼び出しチェーンを通じて末端まで伝搬する | チェーン全体の結合テスト必須 | +| 各モジュールのユニットテストが全てパスしている | ユニットテストのみで十分（上記に該当しない場合） | + ## テスト環境の分離 テストインフラの設定はテストシナリオのパラメータに連動させる。ハードコードされた前提は別シナリオで壊れる。