What are fireEvent and user-event, and why prefer user-event?

WHAT THIS TESTS: This question checks whether you understand the abstraction layers in Testing Library and why testing through user behavior matters more than testing implementation details. Interviewers want to see that you know fireEvent is a low-level utility while user-event models real browser behavior.

A GOOD ANSWER COVERS four things in order. First, define fireEvent as a lightweight wrapper around the browser's dispatchEvent API that lets developers trigger any single event on any element directly. Second, define user-event as a companion library that simulates full user interactions by dispatching the multiple events that a browser would fire, such as focusing an input before typing and firing keyboard and input events in sequence. Third, explain the guardrails: user-event performs visibility and interactability checks so it will not click a hidden element or type into a disabled text box, which fireEvent allows. Fourth, state the practical recommendation: call userEvent.setup before rendering and use its instance methods for most interactions, reserving fireEvent only for edge cases that user-event does not yet support.

COMMON WRONG ANSWERS include saying the two libraries are interchangeable, claiming fireEvent is faster or more explicit so it should be the default, or describing user-event as merely syntactic sugar. Another red flag is suggesting that fireEvent is more reliable because it bypasses browser checks; that bypass is exactly the problem because it lets tests pass when the UI would actually break for a real user.

LIKELY FOLLOW-UPS include asking when fireEvent is still appropriate, which is when you need to dispatch a specific event that user-event has not implemented. An interviewer might also ask how to set up user-event correctly, and you should mention invoking userEvent.setup before rendering and avoiding its use in before or after hooks. They might also ask how user-event handles complex sequences like tab navigation or clipboard operations.

ONE CONCRETE EXAMPLE: when a user types into a text box, the browser focuses the element, updates the selection, fires keydown and keypress events, manipulates the value, fires input, and then fires keyup. fireEvent.change or fireEvent.keyDown would only fire one of those events, potentially missing bugs in event handlers. userEvent.type performs the entire sequence and verifies the element is visible and enabled, catching accessibility and interaction bugs that fireEvent would silently ignore.