test-component
test-component is the guidance for testing one component or hook in isolation —
fast tests that exercise behaviour the way a user does, with the network mocked.
It is the broad base of the testing pyramid: where most of your front-end
confidence should come from, because these tests are quick and stable.
What it solves
Component tests usually fail in one of two directions. Too coupled — asserting on
CSS classes, internal useState, or render order — and every refactor breaks
them. Too shallow — mocking the service layer instead of the network — and they
pass while the real wiring is broken. Either way the suite stops meaning
anything. This skill draws the lines that keep component tests honest and
maintainable.
How it works
The core principle is test behaviour, not implementation:
- Query by accessibility — find elements by role and label, the way a user (or a screen reader) does, not by test-id or CSS selector.
user-event, notfireEvent— model real interactions (typing, clicking, tabbing) rather than raw DOM events.- Mock at the network boundary with MSW — intercept HTTP, not the
service/
axioslayer, so the component’s real data wiring is under test. - A clear line vs E2E — component tests cover one component/hook with the
network mocked;
test-e2ecovers the assembled app in a real browser. Don’t re-test in E2E what a fast component test already proves.
When to use
Writing tests for a component, hook, or form. It pairs with frontend-patterns
(where those components are built) and complements test-e2e — together they are
the front-end half of the testing pyramid.