Topologies

A topology answers where the test runs and against what. It is a different question from the typology, and collapsing the two is the most common structural mistake in a test strategy.

“An integration test” names a typology. It says nothing about whether it runs against an in-process fake, a container started for the test, a shared environment or a live system — and that is the half that decides what it costs, how fast it fails, how often it lies, and what it actually proves.

The four contexts

Context	What is real	Feedback	Fidelity	Fails because
In-process	Your code only	Milliseconds	Low	Your logic is wrong
Ephemeral	Your code + real technology, started per run	Seconds	Medium	Your logic, or how you use that technology
Deployed	The assembled system, real config, real network	Minutes	High	Anything, anywhere in the stack
Production	Everything, including real users and real data	Continuous	Total	Anything — and it matters

The whole design of a suite is a walk down this table: push every check as far up as it can go honestly, and pay for the lower rows only where the fidelity is the point.

The trade being made

Each step down buys fidelity and sells three things, and it is worth being explicit about all three because teams usually only account for the first.

Speed. Milliseconds to seconds to minutes. This determines where the check can sit: a suite that takes 40 minutes cannot gate a merge, and a check outside the merge path finds defects after they have been built on.

Determinism. Every layer of reality adds a way to fail for reasons unrelated to the change — a network hiccup, a container that started slowly, another test’s leftover data. This is not a quality problem to be fixed by better engineering alone; it is inherent to the context. See determinism.

Diagnosability. An in-process failure names the function. A deployed failure names “checkout”, and finding the cause is a bisection across ten components.

Against those three, the thing bought is the only thing that matters at the end: whether the answer is true of the system anyone will actually use.

The pages here

• Suite shapes — pyramid, trophy, honeycomb, and what those arguments are actually about.
• Environments — ephemeral versus shared, and why the shared integration environment fails in the same way everywhere.
• Test data — synthesised, seeded, subsetted or masked, and how the choice constrains everything above it.
• In production — the mechanics of the option described in testing in production.

The recurring mistake

A high-fidelity context used for a check that did not need it.

It looks like this: a validation rule tested through a browser, against a deployed environment, with a seeded user — 90 seconds, flaky, and it fails when someone changes a CSS class. The same rule as a unit test is 4 milliseconds and fails only when the rule changes.

The reason it happens is rarely ignorance. It is that the deployed environment already exists and the browser test framework is already set up, so the expensive path is the one with the least friction on the day. That is a platform problem and it is fixed by making the cheap contexts cheap to reach — which is most of what environments is about.