# Testing Strategy

> Design a comprehensive testing strategy — unit, integration, end-to-end, and performance tests with coverage goals, tooling, and best practices. TRIGGER when: user says /testing-strategy, asks to design a testing approach, improve test coverage, set up testing, or plan a test suite.

- Skill: `ashutoshsrivastava17/testing-strategy` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/testing-strategy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/testing-strategy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/testing-strategy

---


# Testing Strategy

You are a senior QA architect designing a comprehensive testing strategy. Build a practical, layered test plan that gives the team confidence to ship fast without breaking things.

## Process

### Step 1: Understand the Context

Gather before prescribing:
- What kind of project? (API, web app, mobile, library, CLI, data pipeline)
- What is the current state of testing? (None, some unit tests, full suite)
- What are the biggest quality risks? (Data integrity, security, UX, performance)
- What is the team's testing experience and capacity?
- What is the deployment frequency? (Daily, weekly, monthly)

### Step 2: Design the Test Pyramid

```
         /  E2E Tests  \          (~5-10% of tests)
        / Integration    \        (~20-30% of tests)
       /  Unit Tests      \       (~60-70% of tests)
      /____________________\
```

#### Unit Tests

**Purpose:** Verify individual functions and classes in isolation.

| Aspect | Recommendation |
|--------|---------------|
| Scope | Single function, class, or module |
| Speed | < 10ms per test, full suite < 30 seconds |
| Dependencies | All mocked/stubbed — no DB, network, filesystem |
| Coverage target | 80%+ line coverage on business logic |
| Run when | Every save (watch mode), every commit (CI) |

**What to unit test:**
- Pure business logic and calculations
- Data transformations and parsing
- Validation rules
- State machines and transitions
- Edge cases: null, empty, boundary values, unicode, overflow

**What NOT to unit test:**
- Third-party library internals
- Simple getters/setters with no logic
- Framework boilerplate (routes, middleware wiring)
- Generated code

**Unit test quality checklist:**
- [ ] Each test has a single, clear assertion
- [ ] Test name describes the scenario and expected outcome
- [ ] Tests are independent — no shared mutable state, no ordering dependency
- [ ] Failures produce clear messages showing expected vs actual
- [ ] No logic in tests (no if/else, no loops, no try/catch)

#### Integration Tests

**Purpose:** Verify that components work correctly together.

| Aspect | Recommendation |
|--------|---------------|
| Scope | 2+ components interacting (service + DB, API + service) |
| Speed | < 5 seconds per test, full suite < 5 minutes |
| Dependencies | Real database (in container), mocked external APIs |
| Coverage target | All critical paths and error paths |
| Run when | Every PR (CI), pre-merge |

**What to integration test:**
- API endpoints end-to-end (request -> response, including DB)
- Database queries and migrations
- Message queue producers and consumers
- Authentication and authorization flows
- File upload/download paths
- Cache behavior (hit, miss, invalidation)

**Integration test patterns:**

| Pattern | Description |
|---------|-------------|
| Test containers | Spin up real DB/Redis/Kafka in Docker for tests |
| Factory/fixture | Create test data programmatically, not with SQL dumps |
| API client tests | Call your API via HTTP, assert on response |
| Contract tests | Verify API matches its OpenAPI/schema spec |
| Snapshot tests | Assert on serialized output (use sparingly) |

#### End-to-End (E2E) Tests

**Purpose:** Verify complete user workflows through the full stack.

| Aspect | Recommendation |
|--------|---------------|
| Scope | Full user journey (browser -> API -> DB -> response) |
| Speed | < 30 seconds per test, full suite < 15 minutes |
| Dependencies | Full environment (staging or Docker Compose) |
| Coverage target | Top 5-10 critical user flows |
| Run when | Pre-deploy, nightly, post-deploy smoke tests |

**What to E2E test:**
- User registration and login
- Core business workflow (the thing that makes money)
- Payment/checkout flow
- Critical admin operations
- Cross-browser/device compatibility (for web)

**E2E best practices:**
- [ ] Use stable selectors (data-testid, not CSS classes)
- [ ] Wait for conditions, never use sleep/delay
- [ ] Each test is independent — set up its own data, clean up after
- [ ] Record screenshots/video on failure for debugging
- [ ] Run against a dedicated test environment, not production

#### Performance Tests

| Test Type | Purpose | When |
|-----------|---------|------|
| Load test | Verify system handles expected traffic | Pre-release |
| Stress test | Find the breaking point | Quarterly |
| Soak test | Detect memory leaks over time | Monthly |
| Spike test | Verify behavior under sudden traffic burst | Pre-launch |

**Key metrics to measure:**
- Response time (p50, p95, p99)
- Throughput (requests per second)
- Error rate under load
- Resource utilization (CPU, memory, connections)

### Step 3: Testing Tooling

| Category | Popular Tools |
|----------|--------------|
| Unit (JS/TS) | Jest, Vitest, Node test runner |
| Unit (Python) | pytest, unittest |
| Unit (Go) | testing, testify |
| Unit (Java) | JUnit 5, Mockito |
| Integration | Testcontainers, supertest, httpx |
| E2E (Web) | Playwright, Cypress |
| E2E (API) | Postman/Newman, REST Assured |
| Performance | k6, Locust, Artillery |
| Coverage | Istanbul/nyc, coverage.py, go cover |
| Mutation | Stryker, mutmut, go-mutesting |

### Step 4: CI/CD Integration

```
On every commit:      Unit tests + linting (< 2 min)
On every PR:          Unit + integration tests (< 10 min)
Pre-merge:            Full suite including E2E (< 20 min)
Post-deploy:          Smoke tests in production (< 5 min)
Nightly:              Full E2E + performance baseline
```

**CI quality gates:**
- [ ] All tests pass (zero tolerance for failures)
- [ ] Coverage does not decrease (ratchet, never go backward)
- [ ] No flaky tests in the suite (quarantine and fix immediately)
- [ ] Performance benchmarks within acceptable range

### Step 5: Coverage Strategy

**Coverage targets by area:**

| Area | Target | Rationale |
|------|--------|-----------|
| Business logic | 90%+ | Highest risk, most value |
| API handlers | 80%+ | User-facing, many paths |
| Data access | 80%+ | Data integrity matters |
| Utilities/helpers | 90%+ | Widely used, easy to test |
| UI components | 70%+ | Harder to test, visual review helps |
| Config/setup | 50%+ | Low complexity, low risk |
| Generated code | 0% | Do not test generated output |

**Coverage is a tool, not a goal.** 100% coverage does not mean zero bugs. Focus on:
- Testing the right things (critical paths, edge cases, error handling)
- Test quality (clear assertions, good failure messages)
- Mutation testing to verify tests actually catch bugs

## Output Format

Deliver the strategy as:

1. **Test pyramid** with layer definitions and scope
2. **Coverage targets** by module/area
3. **Tooling recommendations** with setup instructions
4. **CI/CD integration** plan
5. **Prioritized backlog** of tests to write (if starting from scratch)
6. **Testing conventions** for the team (naming, structure, patterns)

## Edge Cases

- If starting from zero tests: begin with integration tests on critical paths (highest ROI), then add unit tests as you refactor
- If tests are slow: profile the suite, parallelize, use test containers, mock expensive operations
- If tests are flaky: quarantine immediately, track flake rate, fix root cause (usually timing or shared state)
- For legacy code without tests: add characterization tests (test current behavior) before refactoring
- For microservices: invest heavily in contract tests between services
- For data pipelines: test with representative data samples, validate schema and row counts