Skip to content

Clarifying user-event's capabilities vs fire-event #1102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jul 10, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion docs/user-event/intro.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,13 @@ factors in that the browser e.g. wouldn't let a user click a hidden element or
type in a disabled text box.
This is
[why you should use `user-event`](https://ph-fritsche.github.io/blog/post/why-userevent)
to test interaction with your components.
to test interaction with your components.

There are, however, some user interactions or aspects of these [that aren't yet implemented and thus can't yet be described with `user-event`](https://github.com/testing-library/user-event/issues?q=is%3Aopen+label%3Aaccuracy%2Cenhancement).
In these cases you can use `fireEvent` to dispatch the concrete events that your software relies on.

Note that this makes your component and/or test reliant upon your assumptions about the concrete aspects of the interaction being correct.
Therefore if you already put in the work to specify the correct aspects of such interaction, please consider contributing to this project so that `user-event` might cover these cases too.

## Writing tests with `userEvent`

Expand Down