All posts / Testing / №09
A passing test doesn’t always mean a working UI
JSDOM can find a button and fire its click handler while, on mobile, overflow: hidden has pushed it out of the user’s reach. Why simulated DOM tests and real-browser tests answer different questions, and how Karma and Vitest Browser Mode fit in.
A passing test doesn’t always mean a working user experience. 👀
Let’s talk about unit testing, integration testing, and why tests pass while users still encounter problems in the browser.
For a long time, tools like Jest with JSDOM have been essential in frontend testing. They let us test DOM interactions and component behavior without launching a real browser.
That’s great for many unit and component tests. But there’s an important limitation:
A simulated DOM is not the same as a real browser.
Imagine a card containing a button that gets pushed outside the visible area on mobile because of overflow: hidden and a responsive layout.
Your test might find the button in the DOM, trigger its click handler, and pass successfully.
But in the actual browser, the user might not even be able to see or reach that button!
The test isn’t necessarily wrong. It may simply be testing something different from what we assumed.
Tools like Karma made it possible to run tests in real browsers, helping us catch browser-dependent behavior that DOM simulations cannot fully reproduce.
Then came Vitest, offering a modern testing experience with support for environments such as JSDOM, alongside Browser Mode, which runs tests in a real browser through providers such as Playwright.
We don’t need to run every test in a real browser. That could increase execution time and maintenance costs unnecessarily.
Instead, we should choose the right testing environment for the behavior we want to verify.
Because ultimately, green tests are valuable, but the user’s actual experience is what matters.