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
The natural next questions
Related governed answers
- Walk me through your CI/CD pipeline, step by step, as it actually exists — not the aspiration.?
- It is 3 a.m. and production is degrading. Walk me through detection, response, and what your MTTR actually is.?
- This platform was substantially built by one founder directing AI agents. If you get hit by a bus — or just burn out — what exactly have we bought?
Want this answered live, on your data?