| name | integration-e2e-testing |
| description | Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria. Use when designing integration tests, E2E tests, or reviewing test quality. |
Integration and E2E Testing Principles
Test Type Definition and Limits
| Test Type |
Purpose |
Scope |
Limit per Feature |
Implementation Timing |
| Integration |
Verify component interactions |
Partial system integration |
MAX 3 |
Created alongside implementation |
| E2E |
Verify critical user journeys |
Full system |
MAX 1-2 |
Executed in final phase only |
Behavior-First Principle
Include (High ROI)
- Business logic correctness (calculations, state transitions, data transformations)
- Data integrity and persistence behavior
- User-visible functionality completeness
- Error handling behavior (what user sees/experiences)
Exclude (Low ROI in CI/CD)
- External service real connections → Use contract/interface verification
- Performance metrics → Non-deterministic, defer to load testing
- Implementation details → Focus on observable behavior
- UI layout specifics → Focus on information availability
Principle: Test = User-observable behavior verifiable in isolated CI environment
ROI Calculation
ROI Score = (Business Value × User Frequency + Legal Requirement × 10 + Defect Detection)
/ (Creation Cost + Execution Cost + Maintenance Cost)
Cost Table
| Test Type |
Create |
Execute |
Maintain |
Total |
| Unit |
1 |
1 |
1 |
3 |
| Integration |
3 |
5 |
3 |
11 |
| E2E |
10 |
20 |
8 |
38 |
Test Skeleton Specification
Required Comment Patterns
Each test MUST include the following annotations:
// AC: [Original acceptance criteria text]
// Behavior: [Trigger] → [Process] → [Observable Result]
// @category: core-functionality | integration | edge-case | e2e
// @dependency: none | [component names] | full-system
// @complexity: low | medium | high
// ROI: [score]
Verification Items (Optional)
When verification points need explicit enumeration:
// Verification items:
// - [Item 1]
// - [Item 2]
EARS Format Mapping
| EARS Keyword |
Test Type |
Generation Approach |
| When |
Event-driven |
Trigger event → verify outcome |
| While |
State condition |
Setup state → verify behavior |
| If-then |
Branch coverage |
Both condition paths verified |
| (none) |
Basic functionality |
Direct invocation → verify result |
Test File Naming Convention
- Integration tests:
*.int.test.* or *.integration.test.*
- E2E tests:
*.e2e.test.*
The test runner or framework in the project determines the appropriate file extension.
Review Criteria
Skeleton and Implementation Consistency
| Check |
Failure Condition |
| Behavior Verification |
No assertion for "observable result" in skeleton |
| Verification Item Coverage |
Listed items not all covered by assertions |
| Mock Boundary |
Internal components mocked in integration test |
Implementation Quality
| Check |
Failure Condition |
| AAA Structure |
Arrange/Act/Assert separation unclear |
| Independence |
State sharing between tests, order dependency |
| Reproducibility |
Date/random dependency, varying results |
| Readability |
Test name doesn't match verification content |
Quality Standards
Required
- Each test verifies one behavior
- Clear AAA (Arrange-Act-Assert) structure
- No test interdependencies
- Deterministic execution
Prohibited
- Testing implementation details
- Multiple behaviors per test
- Shared mutable state
- Time-dependent assertions without mocking