Frontend & browser·topic 13 of 13
Testing a user interface
The pyramid arguments are stale but the vocabulary is not, because the words decide what a failing test actually tells you. The recurring theme is testing what the user does, not how the component does it.
Read in order · tick what you already know
- 01
you tested one function's output for a given input, with nothing else running around it.
Unit test
- 02
you rendered the component, clicked the button as a user would, and asserted on what appeared.
Component test
- 03
you tested several components and the data layer together, with the network stubbed out.
Integration test
- 04
you drove a real browser through the whole signup flow against a running server.
End-to-end test
- 05
the test ran in Node with a fake DOM and passed, then the feature broke in an actual browser.
jsdom
- 06
a real browser ran the tests with no window on screen, on a machine with no display at all.
Headless browser
- 07
the test typed into the field character by character instead of setting the value in one go.
User event simulation
- 08
you deleted the `sleep(500)` because the runner already retries the assertion until it passes or times out.
Auto-waiting
- 09
you intercepted the request at the network layer instead of stubbing the function that makes it.
Network mocking
- 10
you added an attribute to the element purely so the test could find it.
Test id
- 11
the test broke because someone added a wrapping div, not because anything the user sees changed.
Brittle selector
- 12
the test recorded the rendered markup and now fails whenever any of it changes, for any reason.
Snapshot test
- 13
the build failed because a component moved three pixels and the image comparison noticed.
Visual regression test
- 14
the automated check found the missing labels and the contrast failures, and nothing about whether the flow made sense.
Accessibility audit