Frontend testing matured considerably between 2020 and 2026. Vitest replaced Jest for most modern projects; Playwright is the dominant E2E tool; visual-regression testing matured; AI-assisted test generation arrived. Senior interviews increasingly probe for understanding of the modern stack and what is worth running in CI. This guide is the working state of frontend testing in 2026.
The 2026 stack
- Unit / component: Vitest + Testing Library
- Integration: Vitest with MSW for API mocking, or Playwright Component Testing
- E2E: Playwright (sometimes Cypress for legacy)
- Visual regression: Chromatic, Percy, or Playwright’s built-in screenshot diffing
- Accessibility: axe-core (in tests), Pa11y for CI
- Performance: Lighthouse CI, web-vitals library in production
Why Vitest replaced Jest
- Native ESM support
- 10x faster on most projects
- First-class Vite integration (config sharing)
- Compatible Jest API (most migrations are mechanical)
- Better TypeScript story
Many large codebases still use Jest; new projects rarely choose it.
What to test at each level
Unit tests
- Pure functions, utility methods, hooks
- Aim: high coverage of business logic
- Fast, parallelizable, run on every PR
- Avoid testing implementation details
Component tests
- Render a component in isolation
- Test rendering, prop handling, user interactions
- Use Testing Library queries (by role, by label) — accessible by default
- Mock complex dependencies (data fetching, contexts)
Integration tests
- Test multiple components or a full page
- Use MSW (Mock Service Worker) for API mocking
- Cover important user flows (login, checkout, settings)
E2E tests
- Test the full app in a real browser
- Limit to top 5–10 critical paths
- Run against staging or a freshly-deployed test env
- Slow; do not gate every PR on full E2E
Playwright over Cypress in 2026
- Multi-browser support (Chromium, WebKit, Firefox)
- True parallelism out of the box
- Faster test execution
- Better network interception API
- Visual testing built in
- Component testing supported
Cypress remains popular at companies that adopted it earlier; new projects mostly choose Playwright.
The Testing Library philosophy
Test from the user’s perspective:
- Query by role, label, text — what the user perceives
- Avoid querying by class names or test IDs unless necessary
- If a component is hard to test, it is often hard to use
Visual regression
- Capture screenshots; compare to baseline; flag differences
- Catches CSS regressions that other tests miss
- Hard to maintain — every UI change requires baseline approval
- Best at the component-library level (Storybook + Chromatic)
- Riskier at the page level; many false positives from dynamic content
Accessibility testing
- axe-core inside Vitest / Playwright tests catches the WCAG A and AA violations programmatically
- Cannot catch all issues (color contrast in some contexts, focus order)
- Integrate as a check in component tests
- Pair with manual screen-reader testing for critical flows
Performance testing
- Lighthouse CI runs on PRs against the deployed preview
- Set budgets for LCP, INP, CLS
- Fail PR if budgets are missed
- web-vitals library reports real user metrics in production
AI-assisted test generation
By 2026, AI tools generate tests from code:
- Cursor / Copilot can suggest tests for selected functions
- Specialized tools (CodeRabbit, Stainless) generate tests as part of review
- Quality varies — generated tests need human review
- Best for boilerplate (component snapshots, prop variation tests)
- Less good for nuanced edge cases that require domain understanding
What to run in CI
- On every PR: unit tests, component tests, lint, type check, accessibility checks (in unit tests), Lighthouse CI on the preview deployment
- Nightly / pre-deploy: full E2E suite, visual regression
- On merge to main: deploy + smoke tests
- Production: real-user monitoring (web-vitals, Sentry)
Coverage targets
- 80% line coverage for unit / component tests is reasonable
- Coverage is necessary but insufficient — high coverage with bad assertions still fails to catch bugs
- Focus on coverage of business-critical paths
- Do not chase 100% — diminishing returns
Common interview questions
- “How would you test this component?” (given a component)
- “What is the difference between testing implementation vs behavior?”
- “How do you decide what to test E2E vs unit?”
- “Walk me through a flaky test you debugged.”
- “What is the role of visual regression in your test strategy?”
What separates senior from staff
Senior candidates know the tools and write good tests. Staff candidates think about the test strategy at the team level — what is worth running, what to mock, the cost of flaky tests, the CI economy. Principal candidates discuss the long-term cost of test maintenance and the trade between coverage and velocity.
Frequently Asked Questions
Should I migrate from Jest to Vitest?
Worth it for projects on Vite. For Webpack-based projects with stable Jest setup, the gain is smaller. New projects: Vitest.
How do I handle flaky E2E tests?
Common causes: timing (use Playwright auto-wait, avoid fixed delays), shared state (each test should set up its own data), network noise (mock with MSW or Playwright route handlers). If a test is flaky, fix or quarantine — do not retry.
Is Cypress dying?
Not dying, but Playwright is the modern default. Cypress is still actively developed. New teams pick Playwright; existing Cypress shops do not need to migrate.