moai-ref-testing-pyramid

name: moai-ref-testing-pyramiddescription: >  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.when_to_use: >  Use for test-pyramid strategy reference: coverage targets,  unit/integration/e2e test patterns, and quality metrics. Amplifies  manager-develop test-creation and quality-validation work with  production-grade testing patterns.user-invocable: falsemetadata:   version: "1.0.0"  category: "domain"  status: "active"  updated: "2026-03-30"  tags: "testing, pyramid, coverage, tdd, patterns, reference"# MoAI Extension: Progressive Disclosureprogressive_disclosure:   enabled: true  level1_tokens: 100  level2_tokens: 3000

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
  /--------------------\

Coverage Targets by Context

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

Integration Test Patterns

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

Test File Conventions

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

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

• Test distribution follows the pyramid: unit > integration > E2E (show test counts per category)
• Unit tests run in under 30 seconds total
• Integration tests mock external dependencies at the boundary
• No flaky tests in the active suite (run 3x to verify stability)
• Test names describe behavior, not implementation (review naming convention)
• Coverage report shows meaningful assertions, not just line execution