No mocks. No patches.
Most testing philosophies fail on economics rather than on principle. Everyone agrees that testing the real object beats testing a stand-in; almost nobody can afford to construct the real object in a unit test, so the stand-in wins and the suite slowly stops describing the system. The interesting part of this estate's testing position is not the rule. It is why the rule is affordable here.
The four non-negotiables
Quoted from the canonical testing guidance, which is one of the guides with for_llms in its filename — the intended reader was named in the filename before anybody wrote the memory thesis down.
No mocks. No patches.
Compose the real objects in memory instead. Services provide an in-memory composition path, and tests use it. Consequence: a test that passes describes the system, not the test's own scaffolding.
Assert on contracts
Schemas, status codes, persisted artefacts. Not implementation details, and not the shape of an internal call. Consequence: a refactor that preserves behaviour does not rewrite the suite.
Real Chromium for integration tests
Gated on an environment variable naming the executable, and skipping cleanly when it is absent rather than failing or silently passing. Consequence: the same suite runs on a laptop without a browser and in CI with one.
Deploy via pytest
Deploy steps are numbered tests — create, then invoke, then check health — and run top-down. Consequence: a deployment is a thing that can fail loudly at a named step, and the deploy path is exercised by the same tool as everything else.
Why no-mocks is affordable here and not elsewhere
The typed-object layer this estate builds on makes construction cheap: an object can be composed in memory in the time it would take to configure a mock, and every service has an in-memory composition path already written because the type system encouraged one. So the real thing is as easy to instantiate as a stand-in would be, and the economics that normally defeat the rule never bite.
The testing philosophy and the type system are one decision, not two. An estate that adopts the rule without the substrate will find it unaffordable, and will be right.
That is the transferable finding, and it is also the honest limit of the advice: do not adopt this rule in isolation. The measured proof that it works here — the suite size and the wall-clock time it runs in — is taken and published by sg-compute.sgit.ai, and this page links it rather than restating it, per the hub's contract.
The structural-guard pattern
The part of this practice least likely to be found elsewhere. Alongside the behavioural suite there is a small set of CI tests that assert on architecture rather than behaviour: that a particular sentinel default is never used, that a UI concern has not leaked into a layer that should not know about it, that a component's public surface still matches its snapshot.
The rule that keeps the set healthy is the whole idea:
Every guard encodes a rule that was violated at least once.
Guards grown from incidents stay few, stay meaningful, and stay worth the failure they cause. Guards grown from a checklist accumulate, and the first time one of them is wrong the team learns to route around the category. The pattern is the same one the resilience doctrine arrives at from the other direction: design for the failure you had.
Counter-evidence
The discipline is real and the coverage is not what the numbers suggest. Measured in the sg-compute pack as of 24 August 2026, and published here as found:
- CI runs only about two-thirds of the collectible tests. The suite is large and fast; the part of it that actually runs on every push is smaller than the headline count implies.
- Several import-level breakages hide in the un-run third. They do not fail, because nothing collects them.
- One of the four structural guards has never worked. A guard that cannot fail is not a guard; it is a green tick with no referent, which is worse than nothing because it is counted.
- A few tests fail on date arithmetic rather than on the behaviour they were written to check.
All four are measured and published in the sg-compute pack, which is where the numbers live. This site links them and does not re-count.
The finding worth carrying away is not that the coverage is imperfect. It is the same finding the documentation page reaches independently: discipline without tooling is real but fragile. Every one of those four items is a thing a check could have caught and no check was watching for.