Testing Strategy Selection

Overview

Choose the right tests for the right situations. Balance comprehensive coverage with development speed through strategic test type selection.

Core principle: The test pyramid - many unit tests, some integration tests, few E2E tests.

When to Use

Use when:

• Planning test coverage for new features
• Deciding which tests to write first
• Test suite is slow or brittle
• Unclear which testing agent to use
• Balancing coverage vs speed
• Setting up testing infrastructure

The Test Pyramid

       /\
      /E2E\      ← Few (5-10% of tests)
     /------\
    /Integration\ ← Some (20-30% of tests)
   /------------\
  /   Unit Tests  \ ← Many (60-75% of tests)
 /----------------\

Unit Tests (60-75%)

What: Test individual functions/components in isolation

When to write:

• Pure functions
• Business logic
• Data transformations
• Utilities and helpers
• Component rendering (React Testing Library)

Characteristics:

• Fast (<10ms each)
• No external dependencies
• Deterministic
• Easy to debug

Agent: test-writer-fixer

Example:

test('calculateDiscount returns correct percentage', () => {
  expect(calculateDiscount(100, 10)).toBe(90)
  expect(calculateDiscount(50, 25)).toBe(37.5)
})

Integration Tests (20-30%)

What: Test multiple units working together

When to write:

• API endpoints
• Database queries
• Module interactions
• React hooks with side effects
• Service layer logic

Characteristics:

• Moderate speed (100ms-1s)
• May use test database
• Test real interactions
• More realistic than unit tests

Agent: api-tester or test-writer-fixer

Example:

test('POST /api/users creates user in database', async () => {
  const response = await request(app)
    .post('/api/users')
    .send({email: 'test@example.com'})

  expect(response.status).toBe(201)

  const user = await db.users.findUnique({
    where: {email: 'test@example.com'}
  })
  expect(user).toBeDefined()
})

E2E Tests (5-10%)

What: Test complete user flows through UI

When to write:

• Critical user paths (signup, checkout, etc.)
• After unit and integration tests exist
• For smoke testing production
• Complex multi-step workflows

Characteristics:

• Slow (5-30s each)
• Brittle (UI changes break tests)
• Expensive to maintain
• Most realistic

Agent: Playwright or Puppeteer tools

Example:

test('user can complete signup flow', async ({page}) => {
  await page.goto('/signup')
  await page.fill('[name=email]', 'user@example.com')
  await page.fill('[name=password]', 'SecurePass123!')
  await page.click('[type=submit]')
  await expect(page).toHaveURL('/dashboard')
})

Test Selection Decision Framework

For EACH feature, ask:

1. Is it critical to user experience?
   NO → Unit tests only
   YES → Continue to #2

2. Does it involve external systems (DB, API)?
   NO → Unit tests
   YES → Integration tests

3. Is it a critical end-to-end user flow?
   NO → Stop at integration tests
   YES → Add E2E test

4. Does it affect revenue or data integrity?
   YES → All three test types
   NO → Unit + Integration sufficient

Testing Agent Selection

Coverage Targets

Minimum coverage:

• Critical paths: 90%+
• Business logic: 80%+
• UI components: 70%+
• Utilities: 90%+
• Overall project: 70%+

Don't chase 100%:

• Diminishing returns
• Focus on valuable tests
• Some code not worth testing (simple getters, constants)

Testing Workflows by Feature Type

New Feature Development

1. Write unit tests (test-writer-fixer)
   - Core logic
   - Component rendering
   - Edge cases

2. Write integration tests (test-writer-fixer or api-tester)
   - API endpoints
   - Database operations

3. Add E2E test if critical flow (test-writer-fixer)
   - Signup, checkout, etc.

4. Run performance check (performance-benchmarker)
   - If performance-critical feature

Bug Fix

1. Write failing test reproducing bug (test-writer-fixer)
   - Should fail before fix
   - Proves bug exists

2. Fix bug
   - Minimal code change

3. Verify test passes (test-writer-fixer)
   - Proves fix works

4. Run full test suite
   - Ensure no regressions

Refactoring

1. Ensure existing tests pass
   - Baseline before changes

2. Refactor code
   - Improve structure

3. Tests should still pass
   - Proves behavior unchanged

4. Add new tests if coverage improved

Test Maintenance

Keep tests valuable:

• Remove flaky tests (fix or delete)
• Update tests when requirements change
• Delete tests for removed features
• Consolidate duplicate tests
• Keep tests fast (optimize slow ones)

Red flags:

• Tests fail randomly
• Tests take >5 minutes
• Tests break on every code change
• Mocksheavy tests (testing mocks not code)

Quick Reference

New feature: Unit (many) → Integration (some) → E2E (if critical) Bug fix: Reproduce with test → Fix → Verify Refactor: Tests unchanged, code improved API: api-tester for contracts and performance Performance: performance-benchmarker for speed tests Analysis: test-results-analyzer for failure patterns

Testing is investment. Strategic test selection maximizes ROI.