What is it?
Frontend testing has three layers. Unit tests (Vitest) check pure functions. Component tests (Vitest + Testing Library) check a component renders and responds to interaction. End-to-end tests (Playwright) drive a real browser through a real user flow. Each catches a different class of bug.
Why it matters
Tests are how teams ship fast without fear. A PR with tests is one a reviewer trusts. Hiring teams increasingly require testing experience — "how would you test this?" is a standard interview question, and "I don't write tests" is a standard rejection.
What to learn
- The testing trophy: static → unit → integration → e2e (and the right mix)
- Vitest: fast unit + component tests, Jest-compatible API
- Testing Library: query by role/label, test like a user
- The golden rule: test behavior, not implementation
- Playwright: cross-browser e2e, auto-wait, trace viewer
- Mocking: when to mock fetch, when to use MSW
- What not to test: implementation details, third-party code
Common pitfall
Testing implementation details — asserting on state values or internal function calls. When you refactor, those tests break even though behavior didn't change. Test what the user sees and does: "click submit, see success message." Those tests survive refactors.
Resources
Primary (free):
- Testing Library docs · docs
- Vitest docs · docs
- Playwright docs · docs
- Kent C. Dodds — Testing Trophy · article
Practice
Take a component with a form (the signup form from an earlier node). Write three tests: a unit test for the validation function, a component test that fills and submits the form, and a Playwright e2e test that does the whole flow in a real browser. Done when all three pass and you can explain what each layer catches that the others miss.
Outcomes
- Pick the right test layer (unit / component / e2e) for any scenario.
- Query elements by role and label, not by test id or class.
- Write a test that survives a refactor because it tests behavior.
- Set up Playwright and run a cross-browser e2e flow.