Test Strategy

Overview

A test strategy defines the types, scope, tools, and coverage targets for testing across all application layers. It serves as the blueprint for quality assurance — ensuring that every component, integration point, and user workflow is validated before deployment. In the full-lifecycle pipeline, @testing-qa generates the Test Strategy Document in Phase 9, consuming API contracts, domain models, and implementation artifacts from earlier phases.

---

Key Concepts

Test Pyramid

         ╱  ╲              ← E2E Tests (5-10%)
        ╱    ╲                Playwright / Cypress
       ╱──────╲
      ╱        ╲           ← Integration Tests (20-30%)
     ╱          ╲             TestContainers, Spring Boot Test
    ╱────────────╲
   ╱              ╲        ← Unit Tests (60-70%)
  ╱                ╲          JUnit 5 + Mockito, Jest + RTL
 ╱──────────────────╲

Test Types Matrix

Test Type	Scope	Speed	Isolation	Tools (Java)	Tools (React)
Unit	Single class/function	< 50ms	Full (mocked deps)	JUnit 5, Mockito	Jest, RTL
Integration	Multiple components	1-10s	Partial (real DB/MQ)	TestContainers, Spring Test	MSW, Supertest
Contract	API boundary	1-5s	Consumer-provider	Spring Cloud Contract, Pact	Pact JS
E2E	Full user flow	10-60s	None (real system)	Playwright	Playwright
Performance	Load/stress	minutes	None	k6, Gatling	Lighthouse
Mutation	Test quality	varies	Full	PIT Mutation	Stryker

Coverage Targets

Layer	Line Coverage	Branch Coverage	Mutation Score
Domain/Service	90%+	80%+	70%+
Controller/API	80%+	70%+	—
Repository/DAO	70%+	—	—
Configuration	50%+	—	—
UI Components	80%+	—	—

---

Best Practices

1. Follow the test pyramid — Most tests should be fast unit tests; few slow E2E tests
2. Test behavior, not implementation — Test what the code does, not how it does it
3. Use Given-When-Then — Structure all tests with clear arrange-act-assert
4. One assertion concept per test — Test one logical outcome (multiple asserts OK if same concept)
5. Test edge cases explicitly — Null, empty, boundary values, error conditions
6. Keep tests independent — No test should depend on another test’s execution
7. Use factories over fixtures — Test data builders prevent brittle shared state
8. Run tests in CI — Every pull request must pass full test suite

---

Code Examples

✅ Good: Test Strategy Document Template

# Test Strategy Document
project: KYC Platform
version: 1.0.0
date: 2026-02-21

layers:
  - name: Unit Tests
    scope: "Domain services, utilities, mappers"
    framework: "JUnit 5 + Mockito (Java), Jest + RTL (React)"
    coverage_target: "90% line, 80% branch"
    run_on: "Every commit"
    
  - name: Integration Tests
    scope: "Repository, API controllers, message consumers"
    framework: "Spring Boot Test + TestContainers"
    coverage_target: "70% line"
    run_on: "Every PR"
    
  - name: Contract Tests
    scope: "REST API contracts, async message schemas"
    framework: "Spring Cloud Contract"
    coverage_target: "All public endpoints"
    run_on: "Every PR"
    
  - name: E2E Tests
    scope: "Critical user journeys (login, KYC submission, approval)"
    framework: "Playwright"
    coverage_target: "Top 10 user flows"
    run_on: "Nightly + pre-release"
    
  - name: Performance Tests
    scope: "API latency, throughput under load"
    framework: "k6"
    coverage_target: "p99 < 500ms at 1000 RPS"
    run_on: "Weekly + pre-release"

test_data:
  strategy: "Test data builders + TestContainers seed scripts"
  sensitive_data: "Anonymized; never use production data"
  
environments:
  - name: local
    type: "Docker Compose (app + postgres + kafka)"
  - name: ci
    type: "GitHub Actions + TestContainers"
  - name: staging
    type: "AWS ECS (mirrors production)"

❌ Bad: No Strategy

# Testing approach:
- We'll add tests later
- Manual testing is enough for now
- QA team will handle it

---

Anti-Patterns

1. Ice cream cone — More E2E than unit tests (inverted pyramid)
2. No test strategy — Writing tests randomly without coverage plan
3. Testing implementation — Asserting internal method calls instead of behavior
4. Shared mutable state — Tests fail based on execution order
5. Ignoring flaky tests — @Disabled without fixing root cause
6. 100% coverage obsession — Diminishing returns past 90%; focus on critical paths

---

Testing Strategies

• Risk-based testing — Prioritize tests for high-risk, high-impact features
• Continuous testing — Run unit + integration on every commit; E2E nightly
• Shift-left testing — Start writing tests during design phase, not after implementation
• Mutation testing — Validate that tests actually catch bugs (PIT/Stryker)

---

References

• Martin Fowler — Test Pyramid
• Google Testing Blog

---

Related Skills

• Unit Testing
• Integration Testing
• E2E Testing