Jest is the test runner; React Testing Library (RTL) is the rendering + querying layer. Philosophy: test BEHAVIOR (what users see and do), not implementation. Use `render`, query by role/text (`getByRole`, `findByText`), simulate with `userEvent`, assert with `expect`. Mock network with msw, not fetch stubs.
Category
Testing
Unit, integration, E2E, mocking, RTL, Playwright, Cypress.
5 questions
Yes — Jest/Vitest as the runner, Testing Library for components (queries by role, behavior over implementation). Mock fetch with MSW for API flows (intercept network, no `fetch` mocks). Test what the user sees: roles, accessible names, behavior on click/type. Avoid testing internal state or implementation details. Coverage on critical paths; E2E (Playwright) for golden flows.
E2E tests drive the real browser through the real app, hitting (usually) the real or stubbed backend. Cypress runs in-browser with a synchronous-feeling API and time-travel debugging — fast feedback, modern stack. Selenium drives the browser via WebDriver protocol — language-agnostic, broad browser support, slower and flakier. Playwright is the modern alternative to both. Trade-off: E2E catches integration bugs unit tests miss, but is slow, expensive, and flaky if poorly written. Pyramid: many unit, some integration, few E2E.
Vitest/Jest + React Testing Library for unit/integration tests focused on user behavior, Playwright/Cypress for end-to-end critical flows, MSW for mocking the network. Follow the testing trophy — invest most in integration tests.
Pyramid in 2026: many unit tests (pure logic, Vitest/Jest), more integration tests than people expect (component + MSW mocked network, React Testing Library), small E2E suite for top-3 user journeys (Playwright). Test behavior not implementation. Visual regression on key screens. Run the right suite at the right gate — unit pre-push, integration on PR, E2E on main/staging.