Beyond Green Checks: What Unit Tests Cannot See In short: A test asserting an element exists in the DOM says nothing about whether a human can see it. Unit tests run without a layout engine, so pixels, overflow, and stacking are structurally invisible to them. Relying on unit tests alone to approve a shared component library creates a specific kind of false confidence: a green pipeline, full coverage, and a broken screen. An honest false positive shows lab results when a dispatcher hovers a tanker's status badge. Here is a perfectly reasonable test: There is nothing wrong with this test. It checks the component's logic correctly. Weeks later, someone adds to a layout wrapper in the shared library — a sensible change to stop a different component's shadow bleeding out. This test still passes. The element is in the DOM, it has , and its text is right. In a browser, the flyout is now clipped to its container and the dispatcher sees a 20-pixel sliver of a lab report. The test was never wrong. It was answering a different question from the one that mattered. The three blind spots 1. No layout engine Unit tests run in an emulated DOM — jsdom or happy-dom under Vitest. These parse HTML and run JavaScript, but they do not lay anything out. There are no boxes, no line breaks, no flex distribution, no scroll containers. So none of the following can be detected: An element rendered at negative coordinates Text wrapping onto a fourth line and pushing a button out of view A flex child overflowing its parent Two elements overlapping An element clipped by an ancestor's returns zeroes. Every element is the same size, which is no size. You can run Vitest in browser mode against real Chromium, which gets you a genuine layout engine — worth doing for components with real layout logic. Even then, the assertions people write are still assertions, so you get the engine without using it. 2. No global styles Component tests render a component in isolation. That is the point — but it means the CSS reset, the base typography, and the three-tier token variables from Chapter 6 are all absent. If someone deletes from the semantic token file, resolves to nothing and the button renders with no background. In the unit test, no stylesheet was ever loaded, so nothing changed and nothing failed. This is why the token file needs its own test, and why the visual gate has to run with the real stylesheets loaded. 3. No sense of what a person can do A padding token changed from (16px) to (8px) to make a card look tighter on a 4K monitor. No logic changed. Every test passes. The touch targets in the farmer portal are now 30px tall, below the accessible minimum, and warehouse staff wearing gloves cannot reliably hit them. Chapter 6's rule exists for this, and no unit test can tell you it was violated. What unit tests are genuinely good at The answer is not "write fewer unit tests". It is to be clear about their job — and the things below are exactly where they are the cheapest, fastest tool available: Yes: Does an input change update the right internal signal? Does clicking emit the right output with the right payload? Does the adapter map this DTO to that presentation model? (Chapter 7) Does the facade set the error state when the API fails? (Chapter 7) Does detection skip the wrapper when no content is projected? (Chapter 5) Does the discriminated union render the right branch? (Chapter 3) No — do not try: Does it look right? Is the dropdown above the chart? Do the colours meet contrast requirements? Does it still work at 320px wide? Is the touch target big enough? Notice the top list is all behaviour with a defined right answer and the bottom list is all rendering . That is the line. What covers the rest Blind spot Gate Lesson --- --- --- Layout, clipping, stacking, overflow Visual regression on stories 2 Contrast, roles, focus order in CI 3 A removed input breaking consumers API surface diff 4 Whether the whole thing is releasable The ship-or-hold gate 5 "But I thought high coverage meant the library was safe" Coverage is the most-quoted quality metric in the industry, and it is not meaningless — a component with no tests is genuinely riskier than one with tests. So the instinct is sound. The problem is what coverage measures: which lines executed , not whether the result was correct, and certainly not whether it was visible. Take the flyout above. Its component class is fully exercised — the input, the toggle, the template branch. Coverage reports 100%. The that broke it is in a CSS file , which no coverage tool instruments at all. You could reach 100% coverage on a library that renders nothing but blank boxes, because CSS is where most visual bugs live and coverage is blind to it. There is a second, more uncomfortable problem: coverage is easy to raise without raising quality. A test that renders a component and asserts it is truthy executes every line of the constructor and template. It contributes to the number and verifies nothing. Failure…