test-pyramid

Test Pyramid Strategy Skill

Expertise: Test type selection, suite health, test doubles, coverage strategy, CI integration.

Test Type Decision Tree

Is this a user-visible multi-step workflow (login → action → confirmation)?
  → E2E test (Playwright/Cypress/Detox)

Does the code call external systems (DB, API, queue, file system)?
  → Integration test (real or containerized dependency)

Is this pure business logic, calculation, data transformation, conditional?
  → Unit test (fast, isolated, no I/O)

Is this a contract between two services?
  → Contract test (Pact or schema validation)

Healthy Suite Ratios

Layer	Target %	When runs	Max duration
Unit	70%	Every commit	< 2 min
Integration	20%	Every PR	< 5 min
E2E	10%	Pre-release	< 20 min

Suite health signals to act on:

• Tests take > 10 min → too many E2E, not enough unit
• Flake rate > 1% → isolation problems
• Coverage high but bugs still escape → testing implementation, not behavior

Test Doubles Reference

Situation                                      → Double
──────────────────────────────────────────────────────────
Verify a function WAS called                   → Mock
Control what a dependency returns              → Stub
Need working but simplified implementation     → Fake (in-memory DB)
Observe calls without replacing behavior       → Spy

Golden rule: Never mock what you don't own. Wrap third-party libraries in your own adapter → mock the adapter.

# ❌ Mocking requests directly
with patch("requests.get") as mock:
    mock.return_value.json.return_value = {"status": "ok"}

# ✅ Mock your own wrapper
class HttpClient:
    async def get(self, url: str) -> dict: ...

class FakeHttpClient:
    async def get(self, url: str) -> dict:
        return {"status": "ok"}

service = MyService(http_client=FakeHttpClient())

Coverage Strategy (Risk-Based Priority)

Coverage is a floor, not a ceiling. Priority:

1. Data mutations — anything that writes to DB
2. Business rules — validation, state machines, calculations
3. Error paths — what happens when things fail
4. Integration boundaries — DB queries, API calls, queue messages
5. Happy path UI flows — last, most expensive