integration-e2e-testing
Scannednpx machina-cli add skill shinpr/claude-code-workflows/integration-e2e-testing --openclawFiles (1)
SKILL.md
3.8 KB
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
Source
git clone https://github.com/shinpr/claude-code-workflows/blob/main/skills/integration-e2e-testing/SKILL.mdView on GitHub Overview
Provides test type definitions and limits for integration and E2E tests, a behavior-first framework, ROI calculation, and skeleton/review criteria. It also covers EARS mapping, file naming conventions, and practical guidance for improving test quality across CI/CD.)
How This Skill Works
It defines limits per test type (integration vs E2E), presents the ROI formula, and prescribes a standard test skeleton with required comments. It also maps tests to EARS keywords, specifies naming conventions, and establishes review criteria to ensure observable, deterministic behavior in CI.
When to Use It
- Designing integration tests to verify component interactions with defined limits per feature
- Creating E2E tests to validate critical user journeys in the final phase
- Calculating ROI to prioritize test cases by business value, user frequency, and defect detection
- Drafting test skeletons with required annotations such as AC, Behavior, category, dependency, complexity, and ROI
- Reviewing test quality and consistency using skeleton/implementation criteria and mock boundary guidance
Quick Start
- Step 1: Define test type and limits for the feature (integration vs E2E) and note max counts per feature
- Step 2: Compute ROI using the ROI formula and record ROI in the test skeleton
- Step 3: Implement the test with the required skeleton comments and verify observable results using AAA
Best Practices
- Verify one behavior per test to keep tests focused
- Maintain a clear AAA (Arrange-Act-Assert) structure and observable result assertions
- Use the required skeleton annotations including AC, Behavior, category, dependency, complexity, and ROI
- Avoid external service real connections and UI layout specifics in CI by using contract verification and observable behavior
- Ensure tests are deterministic, independent, and reproducible in CI environments
Example Use Cases
- Integration test confirming business logic correctness, data integrity, and error handling for a data transformation feature
- E2E test validating a full checkout flow from cart to payment in a production-like environment
- ROI-driven prioritization example showing how ROI Score guides test selection between unit, integration, and E2E tests
- Skeleton file containing AC and Behavior lines plus category, dependency, complexity, and ROI annotations
- Review of test independence and mock boundary to ensure no state leakage between tests
Frequently Asked Questions
Add this skill to your agents
