Testing Standards¶

Status: 🟢 Active | Owner: Engineering Enablement | Last Reviewed: 2025-Q4

Introduction¶

Tests are not optional quality checks appended after development — they are the mechanism by which the organisation makes confident, rapid change. A well-tested codebase allows any engineer to change any part of the system with confidence. An untested codebase is a slow-moving codebase, because every change carries unknown risk.

Testing standards at this organisation enforce quality as a default: coverage thresholds block CI, test data practices are defined, flakiness is treated as a defect, and performance regression detection is built into the delivery pipeline. The result is a system where the cost of change stays low as the system grows.

The Testing Pyramid¶

         ▲
        /E2E\            Few, slow, high-confidence (critical journeys)
       /─────\
      / Intgn  \         Moderate, real dependencies (Testcontainers)
     /──────────\
    /  Unit Tests \      Many, fast, fully isolated (85% coverage gate)
   /──────────────\

Layer	Target % of Suite	Speed	Scope
Unit	~70%	Milliseconds	Single class/function in isolation
Integration	~20%	Seconds	Service + real dependencies
E2E	~10%	Minutes	Full user journey across services

Coverage Requirements¶

Layer	Minimum Coverage	Enforced By
Unit tests	85% line coverage	SonarQube quality gate
Integration tests	All key paths covered	PR checklist + architecture review
E2E tests	All critical user journeys	Release readiness checklist

Coverage thresholds are a floor, not a target. 85% coverage with meaningful tests is far more valuable than 100% coverage with trivial assertions.

Separation of Duties in Testing¶

Clear ownership of test layers prevents both gaps (nobody tests this) and duplication (everyone tests the same thing in different ways).

Test Layer	Owned By	Triggered By	What It Verifies
Unit tests	Engineer authoring the code	Every commit / PR	Business logic correctness
Integration tests	Squad	Every PR (CI)	Service behaviour against real dependencies
Contract tests	Consumer team (consumer-driven)	Every PR on both sides	API contract between producer and consumer
E2E tests	Squad or QA	Pre-release / nightly	Critical user journeys end-to-end
Performance tests	Squad + SRE review	Pre-release / weekly	Latency and throughput SLOs
Exploratory / UAT	QA / Product	Release gates	User experience and edge cases

The squad is accountable for all layers of their service's test suite. SRE reviews production readiness but does not own service-level tests. Product is the final gate for user acceptance — not a substitute for automated testing.

What You Will Find Here¶

Page	Intent
Testing Philosophy	The testing pyramid, core principles, and test layer guidance
Unit Testing	Coverage requirements, AAA pattern, mocking rules, parameterised tests
Integration Testing & Contract Tests	Testcontainers, database isolation, consumer-driven contract tests with Pact
E2E Testing	Playwright standards, Page Object Model, flakiness prevention
TDD & BDD	Test-driven development workflow and behaviour-driven development with Gherkin
Test Data Management	Object Mother, test builders, database isolation, privacy compliance
Performance & Load Testing	k6 standards, SLO-based gates, CI integration

Key Standards at a Glance¶

Standard	Rule
Coverage gate	85% line coverage required; CI blocks below threshold
Test independence	Every test creates and cleans up its own data
No production data in tests	Synthetic or anonymised data only
Flaky tests	Treated as defects; must be fixed or deleted — not skipped
Contract tests required	All cross-service APIs must have consumer-driven contract tests
Performance baseline	Established at first production deployment; regression alerts on breach
Feature flags tested	Both flag-on and flag-off paths must be tested

Last reviewed: 2025-Q4 | Owner: Engineering Enablement