Unit Testing UI Components: Beyond the DOM Mock
Unit tests for UI components verify individual pieces in a mocked browser environment (jsdom). This is standard for checking component logic with Jest or Vitest, but it can't test visual rendering, element sizes, or layout, creating critical blind spots.
Why it exists
To provide a fast, automated way to verify the logic and behavior of individual UI components in isolation. This allows developers building a design system or component library to catch regressions quickly without needing to run a full application.
The mental model
Think of it as testing a car engine on a stand, separate from the car. You can check if the engine starts, revs, and responds to controls (props and events), but you can't check how it performs on a real road (rendering, layout, responsiveness). The stand is the jsdom mock environment; the road is a real browser.
How it works
Unit tests for UI typically use a test runner like Jest or Vitest in a Node.js environment. Because Node.js has no browser, they rely on a library called jsdom to simulate a browser's DOM. Tools like Testing Library then allow you to "render" your component into this simulated DOM, interact with it (e.g., click a button), and make assertions about its state or output.
When to use it
Use unit tests as the foundational automated testing layer for a component library. They are excellent for verifying component logic, state changes in response to interaction, correct event handling, and the presence of accessibility attributes. They are fast and easy to integrate into CI/CD pipelines.
When not to use it
Do not rely on jsdom-based unit tests for anything requiring a true browser rendering engine. This includes visual appearance, layout calculations, element sizes, and media query behavior. These are blind spots. Snapshot tests, which save a component's output, are often misused to cover these gaps but don't guarantee correct rendering and can become brittle.
One canonical example
A developer writes a unit test for a Button component. The test passes a disabled prop and asserts that the button element has the disabled attribute. The test passes. However, this test cannot verify that the CSS for the [disabled] state (e.g., a gray background and not-allowed cursor) is actually applied and visible. This forces a separate manual check in Storybook or a screenshot test, leading to duplicated effort for the same component state.
Interview question
Which aspect of a UI component cannot be reliably verified using a jsdom-based unit test?
- a.Whether a component's internal state updates correctly after user interaction.
- b.The actual visual rendering, layout, and applied CSS styles of the component.Correct
- c.If the component correctly dispatches events when a user interacts with it.
- d.The presence of specific accessibility attributes on rendered elements.
Why? this is the answer
jsdom simulates the DOM but lacks a true browser rendering engine, meaning it cannot verify visual appearance, layout, element sizes, or how CSS is actually applied and rendered. The other options (state updates, event handling, accessibility attributes) are all aspects of component logic and behavior that jsdom-based tests are designed to cover.
Just read this? Test yourself on what you have been reading.
Read the original → reshaped.so
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on testing — each one lists the topics its interview covers.
See open roles