0%
Testing Components

Testing Components

Query your interface the way a user would, not the way a DOM inspector would

10-15 min

Testing Components

Your signup form is covered by fourteen tests, all green. Last month, a developer replaced <div class="erreur"> with an <Alerte> component that applies generated utility classes. The fourteen tests, which looked for .erreur with querySelector, all turned red at once even though the product worked perfectly. Two hours later they were fixed. Then, the following week, a real bug slipped through: the error message was displayed, but it wasn't linked to the field it concerned, so it was invisible to a screen reader. No test caught it.

Both failures have the same cause. Querying the DOM by CSS class tests the internal structure of the rendered output, not what the user perceives. The structure changes constantly without the behavior changing, which produces false positives; and it stays the same when accessibility degrades, which produces false negatives. The fix is mechanical: find your elements by their accessible role and accessible name, exactly as a screen reader or a keyboard user does. Your tests then become insensitive to style refactors and sensitive to the regressions that actually matter.

Comments

Comments are powered by GitHub Discussions

Sign in with GitHub to join the discussion

Link copied!