Testing a login form with type, selectOptions, click and Enter
Note the password input: it has no textbox role (screen readers don't expose password fields as text boxes), so the test finds it by its label. {Enter} inside type presses Enter, which submits the form.
user-event plays the full sequence of browser events a real person causes (pointer, focus, keys, input, click), so tests catch bugs that a single fireEvent would hide; always setup() it and await every action.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a test (live helper style) for a Newsletter component: typing an email and pressing Enter calls onSubscribe with the email.
Write a test that checks a dialog's "Close" button gets focus first when the dialog opens, using user.tab().
Explain it without notes
Why does Testing Library recommend user-event over fireEvent?
Why must you await user-event calls, and why call userEvent.setup()?
How do you test keyboard navigation and focus with user-event?
When would you still use fireEvent?
Preview
Console
Nothing logged yet.Expected console output
✓ the button is disabled until both fields are filled
✓ submits the typed values
✓ Enter in a field submits the form
✓ clear() empties a field