Passing tests still leave a screen to try
DOM tests, rendered browsers and real devices answer different questions.
When the project growsAbout 2 min read
Start with what the test actually checks
A passing suite means the checks that ran met their assertions. It does not establish every behaviour of the application. A test may check that a save action keeps a draft while never measuring whether the Save button is covered by a footer.
DOM environments such as JSDOM can test meaningful behaviour: events, state changes, accessible structure and aspects of focus. They are much more than tag-existence checks. But they do not perform real layout and painting, so they cannot settle every scrolling or visibility problem.
Use a rendered browser for spatial questions
Open the rendered app at representative compact and wide widths. Reach the bottom action, open and close the companion panel, use the keyboard and return to the original control. Check empty, waiting and error states as well as the populated screen.
A 390px viewport is a useful compact check, not a certificate for every phone. Browser automation can inspect real layout, but an actual device remains valuable for the software keyboard, touch, downloads and sharing. Avoid replacing one kind of evidence with another.
Keep the missing check specific
When a rendered defect escapes a unit test, identify which assumption was missing. Add an appropriate regression check rather than only increasing the test count. A reproducible focus sequence and a screenshot of the obstruction can be more useful than a larger green number.
For My Next Step, I want both the underlying behaviour and the route a person takes through the screen to be examined. Each can fail while the other appears sound.