Skip to main content

Boardroom Answers · Technology & Platform · Operational Excellence

3,577 tests is a number, not a strategy. What do they actually cover, and what do they deliberately not cover?

The question a VP Engineering / Head of Platform asks.

The short answer

A real pyramid: exhaustive unit tests over pure logic, schema contract tests, a build-failing tenant-isolation gate, an AI regression harness with zero model calls, and a thin browser layer on the security path — with the thin spots named.

The full executive answer

Exactly the right challenge — coverage theatre is real, so here is the strategy by layer. The base of the pyramid: unit tests over the pure business logic, and our architecture makes that tractable by convention — each of the 68 domain modules separates its pure, deterministic logic from its side-effectful service layer, so scoring arithmetic, ranking, envelope-building and state machines are tested exhaustively and fast, with no mocking swamp. Above that, contract tests: every API input and every AI output is a typed schema, and the schemas are tested directly. Then the two layers most suites do not have: a static security gate that scans all 192 migrations and fails the build if any tenant table lacks row-level security — a test of the architecture itself — with dedicated cross-tenant attack tests beside it; and the AI evaluation harness, which runs golden fixtures and mutations through every registered AI schema contract on every push with zero model calls, so AI behaviour is regression-tested as rigorously as code.

The top of the pyramid is deliberately thin, per the classic model: a Playwright browser layer currently focused on the security-critical path — proving protected routes reject unauthenticated visitors against a real production build after every merge to main.

What is deliberately not covered, honestly: broad end-to-end journey tests across all 178 pages — thin by choice pre-launch because they are the slowest, most brittle layer, and expanding them is sequenced against real user journeys once launch data shows which journeys matter; live-model AI quality is sampled and evaluated separately rather than gated in CI, because non-deterministic model calls in a build gate produce flaky pipelines, not safety. The strategy is a test pyramid with two extra load-bearing floors — a security gate and an AI-behaviour gate — which is what a governed AI product actually needs.

Grounded in: Test pyramid (Cohn/Fowler); DORA test-automation capability

Want this answered live, on your data?