A test fills a search box with Testing Library's fireEvent.change(input, { target: { value: 'shoes' } }) and the assertion passes. Which real-user behaviours does that single line fail to exercise?

## What the one-liner really does `fireEvent.change(input, { target: { value: 'shoes' } })` does two things: it assigns the value onto the element, then dispatches a single event. In a React app this is enough to make a controlled input update, which is precisely why the pattern is so popular — it looks like it works. But consider what a user did to reach the same state. They focused the field, then pressed five keys. Each key produced its own `keydown`, its own `input`, its own `keyup`, and moved the value through five intermediate states: `s`, `sh`, `sho`, `shoe`, `shoes`. The one-liner reproduces the destination and none of the journey. ## The behaviours that go untested **Keyboard handlers.** No key event is fired at all. A search box that submits on `Enter`, a combobox that opens on `ArrowDown`, a shortcut bound to `Escape` to clear — none of it runs. A test can "fill the search field and assert results appeared" while the field is unusable from a keyboard. **Per-keystroke logic.** Debounced or throttled search, autocomplete suggestion fetching, character counters, live validation and as-you-type masking are all driven by the *stream* of values. A single jump exercises the handler exactly once with a final value, which is often the one input for which the buggy code happens to work. **Browser constraints.** Attributes such as `maxlength` limit what a user can type; they do not limit what code can assign. Assigning a longer string succeeds: ```javascript input.maxLength = 3 fireEvent.change(input, { target: { value: 'abcdef' } }) input.value // 'abcdef' — longer than maxlength allows ``` A typed interaction stops at the limit, which means a test that asserts the component's behaviour past the cap is testing a state the product can never be in. **Caret and selection.** Typing happens at the caret. Formatting logic that reinserts separators into a card number, or that uppercases input, must preserve the caret position, and that bug class only appears when characters arrive one at a time in the middle of an existing value. A whole-value assignment always looks like an append to the end. **Focus.** `fireEvent.change` does not focus the field. Validation that runs on blur, a label that animates on focus, or an "unsaved changes" guard armed on first focus stays dormant. ## What the interaction-level API does instead ```javascript const user = userEvent.setup() await user.click(input) await user.type(input, 'shoes') ``` `user.type` focuses the element, then for each character dispatches the key events a real keyboard produces along with the resulting `input` event, honouring the field's constraints as it goes. `user.clear(input)` selects the content and deletes it the way a user would rather than assigning an empty string. `user.keyboard('{Enter}')` presses a key rather than pretending one was pressed. Note one important default: `type` **appends** to whatever is already in the field, just as typing does. Tests that assumed `change`'s replace-everything semantics often surface here first, and the fix is to clear explicitly rather than to go back to assignment. ## The cost, and when it is acceptable Character-by-character typing costs more time than one assignment, and for a long string in a form with many fields that adds up. Two honest mitigations exist: type a short representative value rather than a realistic-length one, and reserve full typing for the field whose behaviour is under test while setting unrelated fields more cheaply. What is *not* a good trade is filling the field under test with a single change event because typing was slow — that is exactly the field where the missing events matter. ## How to talk about it in an interview The crisp framing is that `fireEvent.change` asserts a **state transition** while typing asserts an **interaction**. If the thing you are testing is downstream of the final value only — say, that a submit button enables once the field is non-empty — the cheap version may genuinely be enough. If anything in the component reads keys, counts keystrokes, or cares where the caret sits, the cheap version is a test that cannot fail on the bug you are worried about.