// Designs integration and E2E tests with mock boundaries. Use when: writing E2E tests, integration tests, or reviewing test quality.
| name | integration-e2e-testing |
| description | Designs integration and E2E tests with mock boundaries. Use when: writing E2E tests, integration tests, or reviewing test quality. |
| Type | Purpose | Limit |
|---|---|---|
| Integration Test | Component interaction verification | 3 per feature |
| E2E Test | Critical user journey verification | 1-2 per feature |
| Check | Question | If NO |
|---|---|---|
| Observable | Can user observe the result? | Exclude |
| System Context | Does it require integration of multiple components? | Exclude |
| Automatable | Can it run stably in CI environment? | Exclude |
Include: Business logic accuracy, data integrity, user-visible features, error handling Exclude: External live connections, performance metrics, implementation details, UI layout
Each test skeleton MUST include:
| Step Type | Verification Target |
|---|---|
| Trigger | Reproduce in test setup (Arrange) |
| Process | Intermediate state or function call |
| Observable Result | Final output value (return value, error message, log output) |
Pass Criteria: Test passes if "observable result" is verified as return value or mock call argument
| Judgment Criteria | Mock | Actual |
|---|---|---|
| Part of test target? | No → Can mock | Yes → Actual required |
| External network communication? | Yes → Mock required | No → Actual recommended |
| Check | Failure Condition |
|---|---|
| Behavior Verification | No assertion for "observable result" |
| Verification Item Coverage | Listed verification items not included in assertions |
| Mock Boundary | Internal components mocked in integration test |
| Check | Failure Condition |
|---|---|
| AAA Structure | Arrange/Act/Assert separation unclear |
| Independence | State sharing between tests, execution order dependency |
| Reproducibility | Depends on date/random, results vary |
| Readability | Test name and verification content don't match |
Guides PRD, ADR, Design Doc, and Work Plan creation. Use when: planning features, writing specs, or creating technical documents.
Detects code smells, anti-patterns, and debugging issues. Use when: fixing bugs, reviewing code quality, or refactoring.
Applies coding standards for clean, maintainable code. Use when: writing functions, handling errors, refactoring, or reviewing code style.
Selects implementation strategy (vertical/horizontal/hybrid) with risk assessment. Use when: planning features or deciding development approach.
Validates approach and checks assumptions before/after tasks. Use when: starting work, encountering errors, or switching phases.
Applies TDD process, test quality criteria, and mock guidelines. Use when: writing unit tests, using mocks, or reviewing test quality.