Layered Test Architecture

Use the lowest layer that can prove a risk reliably and quickly. A healthy architecture is not defined by a fixed pyramid percentage; it minimizes slow, fragile feedback while retaining enough end-to-end evidence for critical journeys.

flowchart BT
    S[Static checks] --> U[Unit tests]
    U --> C[Component tests]
    C --> K[API and contract tests]
    K --> I[Integration tests]
    I --> E[Selective E2E tests]
    E --> P[Production checks]
    X[Exploratory testing] -. investigates unknown risk .-> C
    X -.-> K
    X -.-> E
    N[Security performance resilience accessibility] -. crosses layers .-> S
    N -.-> P

What belongs at each layer

Layer	Best use	PeopleFlow example
Static	Find code, dependency, secret, license, and configuration risk without running the product	SAST, dependency and IaC scans
Unit	Prove small deterministic rules quickly	Tax, rounding, leave balance
Component	Test one service with controlled real infrastructure	Payroll service with Testcontainers and a fake banking API
Contract	Protect API and event compatibility	Payroll REST schema and Kafka event contract
API/service	Validate behavior, authorization, errors, boundaries, retry, and idempotency	Start a payroll run and prevent cross-tenant references
Integration	Verify real dependencies and data flow	Payroll to accounting; Kafka to data mart
Selective E2E	Prove a few critical user journeys through the UI	Create employee and complete first payroll
Exploratory	Discover unknown risk and confusing behavior	Ambiguous approval flow or unusual policy question
Production check	Detect configuration and drift safely	Synthetic login, reconciliation, AI-quality monitoring

Maintainable automation design

flowchart LR
    A[Test specifications] --> B[Domain workflows]
    B --> C[Interface adapters]
    C --> D[Application and dependencies]
    E[Test data and fixtures] --> B
    F[Environment configuration] --> C
    G[Execution orchestration] --> A
    D --> H[Evidence logs traces reports]

Keep business intent separate from UI selectors, HTTP clients, database queries, Kafka adapters, and AI evaluators. Isolate test data by tenant and run ID. Avoid fixed sleeps; wait for an observable condition. Give flaky tests an owner and repair deadline, and never let quarantine hide a critical control.

API example: POST /payroll-runs

• A payroll specialist can start one run.
• An employee receives 403.
• Reusing an idempotency key does not create another run.
• Retrying after a timeout does not duplicate payments.
• One tenant cannot reference another tenant's employees.
• Final state and audit evidence remain correct after partial failure.

Back to index