integration-e2e-testing

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