Gate 1 — Multi-Gate Testing: Confidence Over Coverage The first gate is the one everyone thinks they already have: testing. Most teams do have tests . What they usually do not have is a testing architecture — a clear plan for what is checked, at which layer, with which tool, catching which kind of failure. Without that plan, "we have tests" really means "we have a pile," and a pile tells you nothing about what is actually protected. This gate replaces the pile with a structure: separate sub-gates, each with one job, each clear about what it catches. The idea underneath is the one from Chapter 1 — test where failure is expensive, not where it is easy — turned into an actual layout. The problem this gate solves A single mixed-up test suite has a specific weakness. When it turns red, you do not know right away what kind of thing broke. Was it pure logic? A rendering problem? A broken contract with another team? An integration issue that only shows up once the code is built? Each of those has a different owner, a different fix, and a different urgency. A mixed suite makes you work that out from scratch every time. Worse, a mixed suite tends to test everything at the most expensive layer available. People reach for a full browser render to check logic that is really just a plain function, because that is the tool that is set up. The result is slow, flaky (fails randomly), and unclear — the opposite of what a gate should be. The layers, at a glance The multi-gate model splits testing into separate jobs, running the fastest and cheapest first: Logic gate — pure functions, state machines, headless hooks (logic with no UI attached). No DOM, no CSS. Runs in milliseconds, on every save. This is where you check decisions : what is selected, what a key press means, edge cases. Interaction gate — the full component in a real DOM. Keyboard navigation, focus order, ARIA state (the accessibility labels screen readers rely on), and automatic accessibility checks. This is where you confirm a human can actually use the thing. Contract gate — the public API other teams depend on. Teams declare what they expect, and it is checked in CI, so an incompatible change fails your build before it reaches anyone. Integration smoke gate — the built, shipped package in a near-real environment. Does it mount and unmount cleanly? Does theming work? A real browser, not a fake one. Each layer catches something the others cannot. Logic tests cannot catch a focus-order bug. Interaction tests cannot catch a silent contract break. Contract tests cannot catch a memory leak on unmount. That is the whole reason for splitting them. Why separating the layers matters The value of the split is not tidiness. It is clear diagnosis and speed . When a logic test fails, you know a decision broke — and you know it in milliseconds, without starting a browser. When a contract test fails, you know a promise to another team broke, before publish. When the integration smoke test fails, you know the pieces do not fit together even though each passed alone. The failing gate names the kind of problem — which is exactly the thing a mixed suite hides when it turns red. The speed order matters too. Cheap, fast gates run all the time and catch most mistakes as you write them. Expensive, slow gates run less often and catch the rarer, whole-system problems. You get fast feedback at the bottom and strong confidence at the top, instead of paying full price on every check. What this gate is not It helps to be clear about what this gate does not try to do: It is not a coverage number. As Chapter 1 argued, the target is functional coverage against the contract — every promise checked — not a line percentage. It is not full end-to-end testing. The integration smoke layer checks the critical paths of the platform package . It does not replace the app-level end-to-end tests that consuming teams own. It is not a home for flaky tests. A test that fails randomly in this gate is a bug to fix, not something to retry around — a theme the determinism chapter takes up in full. Where this goes next This lesson is the outline. Part II fills it in: the multi-gate model in detail (Chapter 3), consumer-driven contracts and API-surface safety (Chapter 4), and the automation architect's signature skill — determinism and flaky-test governance (Chapter 5), which is what keeps this whole gate trustworthy rather than just present. Gate 1 in one line: Testing is not a pile and not a percentage — it is a set of layers, each owning one expensive failure, each naming the problem when it breaks.