Testing Pyramid Reference
Target Agents
manager-develop - applies patterns during test creation, coverage analysis, and RED-GREEN-REFACTOR cycles
Test Pyramid Ratios
/ E2E \ 10% — Critical user journeys only
/----------\
/ Integration \ 20% — API endpoints, DB queries, service boundaries
/----------------\
/ Unit Tests \ 70% — Functions, hooks, utilities, pure logic
/--------------------\
| Level |
Speed |
Reliability |
Maintenance |
Coverage Target |
| Unit |
Fast (<100ms) |
High |
Low |
70% of tests |
| Integration |
Medium (1-5s) |
Medium |
Medium |
20% of tests |
| E2E |
Slow (10-60s) |
Lower |
High |
10% of tests |
Coverage Targets by Context
| Context |
Target |
Rationale |
| Critical business logic |
95%+ |
Revenue/security impact |
| API endpoints |
90%+ |
Contract compliance |
| Utility functions |
85%+ |
Reuse reliability |
| UI components |
80%+ |
Rendering correctness |
| Configuration/glue code |
60%+ |
Low complexity |
| Generated code |
0% |
Don't test generated code |
Test Pattern: AAA (Arrange-Act-Assert)
// Arrange: Set up test data and preconditions
input := CreateTestUser("test@example.com")
// Act: Execute the function under test
result, err := service.CreateUser(ctx, input)
// Assert: Verify the outcome
assert.NoError(t, err)
assert.Equal(t, "test@example.com", result.Email)
Unit Test Patterns
| Pattern |
When |
Example |
| Table-Driven |
Multiple input/output combinations |
Go: tests := []struct{...} |
| Mock/Stub |
External dependencies (DB, API) |
Interface injection, mock frameworks |
| Snapshot |
Complex output comparison |
Jest snapshots, golden files |
| Property-Based |
Mathematical properties |
quickcheck, hypothesis |
| Boundary Value |
Edge cases |
0, -1, MAX_INT, empty string, nil |
Integration Test Patterns
| Pattern |
When |
Example |
| Testcontainers |
Real DB needed |
Docker-based PostgreSQL for tests |
| HTTP Test Server |
API endpoint testing |
httptest.NewServer (Go), supertest (Node) |
| In-Memory DB |
Fast DB tests |
SQLite for development |
| Fixture Loading |
Consistent test data |
Factory functions, seed files |
What to Test vs What NOT to Test
ALWAYS Test
- Business logic and calculations
- Input validation and error handling
- Authentication and authorization flows
- Data transformations and mappings
- Edge cases and boundary conditions
- Race conditions (with -race flag in Go)
NEVER Test
- Framework internals (React rendering, Express routing)
- Third-party library behavior
- Simple getters/setters with no logic
- Private methods directly (test via public API)
- Generated code (protobuf, swagger)
- CSS styling and layout (use visual regression tools instead)
Test Quality Metrics
| Metric |
Target |
Tool |
| Line Coverage |
85%+ |
go test -cover, istanbul, coverage.py |
| Branch Coverage |
75%+ |
go test -covermode=count |
| Mutation Score |
70%+ |
go-mutesting, Stryker |
| Test Execution Time |
<2 min (unit), <10 min (all) |
CI timer |
| Flaky Test Rate |
<1% |
CI history analysis |
Test File Conventions
| Language |
Test File |
Location |
| Go |
*_test.go |
Same package |
| TypeScript |
*.test.ts / *.spec.ts |
__tests__/ or co-located |
| Python |
test_*.py |
tests/ directory |
| Java |
*Test.java |
src/test/ mirror |
| Rust |
#[cfg(test)] mod tests |
Same file or tests/ |
TDD RED-GREEN-REFACTOR Quick Reference
RED: Write a failing test that defines expected behavior
GREEN: Write minimal code to make the test pass
REFACTOR: Clean up while keeping tests green
Rules:
- Never write production code without a failing test
- Write the smallest test that fails
- Write the simplest code that passes
- Refactor only when all tests are green
- One assertion per test (when practical)
Common Rationalizations
| Rationalization |
Reality |
| "E2E tests cover everything, unit tests are redundant" |
E2E tests are slow and flaky. Unit tests provide fast, precise feedback. The pyramid exists because each level serves a different purpose. |
| "Integration tests are more realistic than unit tests" |
Realism comes at the cost of speed and isolation. A balanced pyramid gives both fast feedback and realistic validation. |
| "100% code coverage means the code is well tested" |
Coverage measures execution, not correctness. A test that executes code without meaningful assertions provides zero value. |
| "Mocking is bad, I prefer real dependencies" |
Real dependencies make tests slow and non-deterministic. Mock at boundaries, test business logic in isolation. |
| "This test is flaky, but it catches real bugs sometimes" |
Flaky tests erode trust in the entire suite. Fix the flakiness or quarantine the test with a tracking issue. |
DAMP over DRY: Test code should be descriptive and self-contained. A reader should understand the test without reading shared fixtures or helper methods.
Red Flags
- Test pyramid inverted: more E2E tests than unit tests
- Unit tests depend on external services (databases, APIs, file systems)
- Test assertions check implementation details instead of behavior
- No integration tests between unit and E2E layers
- Flaky test present without a quarantine label or tracking issue
Verification
1---2name: moai-ref-testing-pyramid-23description: Test pyramid strategy, coverage targets, test patterns, and quality metrics reference. Agent-extending skill that amplifies manager-develop test-creation and quality-validation work with production-grade testing patterns. NOT for: production code implementation, architecture design, DevOps, security audits.4---56# Testing Pyramid Reference78## Target Agents910- `manager-develop` - applies patterns during test creation, coverage analysis, and RED-GREEN-REFACTOR cycles1112## Test Pyramid Ratios1314```15 / E2E \ 10% — Critical user journeys only16 /----------\17 / Integration \ 20% — API endpoints, DB queries, service boundaries18 /----------------\19 / Unit Tests \ 70% — Functions, hooks, utilities, pure logic20 /--------------------\21```2223| Level | Speed | Reliability | Maintenance | Coverage Target |24|-------|-------|-------------|-------------|-----------------|25| Unit | Fast (<100ms) | High | Low | 70% of tests |26| Integration | Medium (1-5s) | Medium | Medium | 20% of tests |27| E2E | Slow (10-60s) | Lower | High | 10% of tests |2829## Coverage Targets by Context3031| Context | Target | Rationale |32|---------|--------|-----------|33| Critical business logic | 95%+ | Revenue/security impact |34| API endpoints | 90%+ | Contract compliance |35| Utility functions | 85%+ | Reuse reliability |36| UI components | 80%+ | Rendering correctness |37| Configuration/glue code | 60%+ | Low complexity |38| Generated code | 0% | Don't test generated code |3940## Test Pattern: AAA (Arrange-Act-Assert)4142```43// Arrange: Set up test data and preconditions44input := CreateTestUser("test@example.com")4546// Act: Execute the function under test47result, err := service.CreateUser(ctx, input)4849// Assert: Verify the outcome50assert.NoError(t, err)51assert.Equal(t, "test@example.com", result.Email)52```5354## Unit Test Patterns5556| Pattern | When | Example |57|---------|------|---------|58| Table-Driven | Multiple input/output combinations | Go: `tests := []struct{...}` |59| Mock/Stub | External dependencies (DB, API) | Interface injection, mock frameworks |60| Snapshot | Complex output comparison | Jest snapshots, golden files |61| Property-Based | Mathematical properties | quickcheck, hypothesis |62| Boundary Value | Edge cases | 0, -1, MAX_INT, empty string, nil |6364## Integration Test Patterns6566| Pattern | When | Example |67|---------|------|---------|68| Testcontainers | Real DB needed | Docker-based PostgreSQL for tests |69| HTTP Test Server | API endpoint testing | httptest.NewServer (Go), supertest (Node) |70| In-Memory DB | Fast DB tests | SQLite for development |71| Fixture Loading | Consistent test data | Factory functions, seed files |7273## What to Test vs What NOT to Test7475### ALWAYS Test76- Business logic and calculations77- Input validation and error handling78- Authentication and authorization flows79- Data transformations and mappings80- Edge cases and boundary conditions81- Race conditions (with -race flag in Go)8283### NEVER Test84- Framework internals (React rendering, Express routing)85- Third-party library behavior86- Simple getters/setters with no logic87- Private methods directly (test via public API)88- Generated code (protobuf, swagger)89- CSS styling and layout (use visual regression tools instead)9091## Test Quality Metrics9293| Metric | Target | Tool |94|--------|--------|------|95| Line Coverage | 85%+ | go test -cover, istanbul, coverage.py |96| Branch Coverage | 75%+ | go test -covermode=count |97| Mutation Score | 70%+ | go-mutesting, Stryker |98| Test Execution Time | <2 min (unit), <10 min (all) | CI timer |99| Flaky Test Rate | <1% | CI history analysis |100101## Test File Conventions102103| Language | Test File | Location |104|----------|-----------|----------|105| Go | `*_test.go` | Same package |106| TypeScript | `*.test.ts` / `*.spec.ts` | `__tests__/` or co-located |107| Python | `test_*.py` | `tests/` directory |108| Java | `*Test.java` | `src/test/` mirror |109| Rust | `#[cfg(test)] mod tests` | Same file or `tests/` |110111## TDD RED-GREEN-REFACTOR Quick Reference112113```114RED: Write a failing test that defines expected behavior115GREEN: Write minimal code to make the test pass116REFACTOR: Clean up while keeping tests green117```118119Rules:120- Never write production code without a failing test121- Write the smallest test that fails122- Write the simplest code that passes123- Refactor only when all tests are green124- One assertion per test (when practical)125126<!-- moai:evolvable-start id="rationalizations" -->127## Common Rationalizations128129| Rationalization | Reality |130|---|---|131| "E2E tests cover everything, unit tests are redundant" | E2E tests are slow and flaky. Unit tests provide fast, precise feedback. The pyramid exists because each level serves a different purpose. |132| "Integration tests are more realistic than unit tests" | Realism comes at the cost of speed and isolation. A balanced pyramid gives both fast feedback and realistic validation. |133| "100% code coverage means the code is well tested" | Coverage measures execution, not correctness. A test that executes code without meaningful assertions provides zero value. |134| "Mocking is bad, I prefer real dependencies" | Real dependencies make tests slow and non-deterministic. Mock at boundaries, test business logic in isolation. |135| "This test is flaky, but it catches real bugs sometimes" | Flaky tests erode trust in the entire suite. Fix the flakiness or quarantine the test with a tracking issue. |136137**DAMP over DRY**: Test code should be descriptive and self-contained. A reader should understand the test without reading shared fixtures or helper methods.138139<!-- moai:evolvable-end -->140141<!-- moai:evolvable-start id="red-flags" -->142## Red Flags143144- Test pyramid inverted: more E2E tests than unit tests145- Unit tests depend on external services (databases, APIs, file systems)146- Test assertions check implementation details instead of behavior147- No integration tests between unit and E2E layers148- Flaky test present without a quarantine label or tracking issue149150<!-- moai:evolvable-end -->151152<!-- moai:evolvable-start id="verification" -->153## Verification154155- [ ] Test distribution follows the pyramid: unit > integration > E2E (show test counts per category)156- [ ] Unit tests run in under 30 seconds total157- [ ] Integration tests mock external dependencies at the boundary158- [ ] No flaky tests in the active suite (run 3x to verify stability)159- [ ] Test names describe behavior, not implementation (review naming convention)160- [ ] Coverage report shows meaningful assertions, not just line execution161162<!-- moai:evolvable-end -->
modu-ai