testing-library / testing-library/user-event

Migration recommendation: prefer Vitest browser mode or Playwright for new work

Open
#1,319 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

documentation
Dominant language
TypeScript
Stars
2.3k
Forks
258
PR merge metrics
No merged PRs in 30d

Description

Hey folks,

I want to be upfront about where this library sits in 2026.

user-event was built for a world where most component tests ran in jsdom. It does a great job approximating browser behavior by dispatching the right DOM events in the right order. That still matters if your tests run in jsdom/happy-dom.

But if you can run tests in a real browser, you should. The highest-fidelity "user events" are no longer something you need to simulate in userland:

  • Vitest Browser Mode ships a userEvent from vitest/browser that intentionally mirrors this library's API, but drives the browser through CDP/WebDriver instead of faking events. Vitest's own docs recommend that over @testing-library/user-event in browser mode.
  • Playwright (and Playwright component testing) has first-class locator actions (click(), fill(), press(), etc.) with auto-waiting and actionability checks. That's a different API, and for E2E/browser component tests it's usually the better tool.
What I recommend
  • New browser-based tests: use Vitest's userEvent / locators, or Playwright's locators. Don't add @testing-library/user-event there.
  • Existing jsdom/RTL unit tests: this package is still a reasonable choice. No need to rip it out for its own sake.
  • If you're choosing where to invest: prefer moving important interaction tests toward a real browser over deepening reliance on event simulation.
Maintenance reality

This repo is not getting active feature work. I'll still try to keep the lights on for security/release breakage when I can, but I don't want people starting new projects on the assumption that user-event is the long-term center of gravity for user interactions.

Cheers,
Kent

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names Vitest Browser Mode and Playwright as the entry points, contrasting them with jsdom, happy-dom, and existing jsdom/RTL unit tests. Start by reviewing the linked Vitest and Playwright guidance; done would require a project decision about whether and where to record this migration recommendation.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, playwright, typescript
Domain
testing
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.