Course Introduction

Introduction

Intro to module 1

Main features and options

Working with the provided sample codes

Integrating ESLint into your code editor

Setting the plugin up in your project

Run the plugin only on test files

Migrating the plugin to v5

Using the plugin in a Create React App project

Plugin features and set up

Intro to module 2

no-manual-cleanup rule

prefer-screen-queries rule

no-await-sync-query rule

no-await-sync-events rule

no-container rule

no-node-access rule

no-render-in-setup rule

no-wait-for-multiple-assertions rule

prefer-explicit-assert rule

prefer-find-by rule

prefer-user-event rule

prefer-wait-for rule

prefer-query-by-disappearance rule

Rules for following best practices

Intro to module 3

no-dom-import rule

await-async-query rule

await-async-utils rule

await-fire-event rule

no-global-regexp-flag-in-query rule

no-promise-in-fire-event rule

no-wait-for-empty-callback rule

no-wait-for-side-effects rule

no-wait-for-snapshot rule

prefer-presence-queries rule

no-unnecessary-act rule

Rules for preventing errors

Intro to module 4

no-debugging-utils rule

render-result-naming-convention rule

consistent-data-testid rule

Auto-fixing ESLint problems

What is Aggressive Reporting?

Configuring the Aggressive Reporting

Rules for style guidelines & Advanced Features

Testing Library is a great bunch of utils to write tests for your UI. It has become the favorite testing choice of many users since it encourages you to write more maintainable and reliable tests, encourages best practices, and doesn't focus on implementation but behavior.

However, testing your app correctly with Testing Library is not always straightforward. _What query variant fits better for this situation? How should I check appearance/disappearance? What is the best way to handle async behaviors? Why am I seeing this particular error or warning? Why am I not getting the expected element?_ These are very typical questions while writing tests with Testing Library.

You are not alone! This course aims to help you master these situations with the assistance of `eslint-plugin-testing-library`: the official ESLint plugin for Testing Library.

The course will boost your Testing Library skills by using this plugin
as a companion when writing tests. You will get instant feedback by linting your tests code, so you can **follow best practices and anticipate common mistakes for Testing Library**, as well as better understand its utils and their main purposes.

Get ready to say goodbye to flaky tests!

Master writing Testing Library tests with eslint-plugin-testing-library by anticipating common mistakes and following best practices

Master Testing Library with ESLint Plugin

How to set up eslint-plugin-testing-library in your codebase

Getting ESLint feedback directly in your code editor and your terminal

ESLint advanced config for getting more granular control over the linting process

Better understanding of Testing Library errors

Following best practices for Testing Library tests

This rule is compatible with all Testing Library frameworks supported by this plugin.

The Testing Library frameworks provide a built-in utility to fire DOM events over the elements of your UI: 

 will create the desired event and dispatch it on the given DOM node exactly as you tell it and just those, even if those exact events had never been dispatched in a real interaction in a browser.

 as an example. It works properly for most situations when you simply want to test what happens in your UI when your element is clicked. However, when the 

 actually clicks your element, these are the events that are usually fired (in order):

Another example would be testing how an input handles the values typed. This is usually performed with 

, where you need to pass the element to dispatch the event and the actual event object to be dispatched: 

fireEvent.keyDown(element, target: { value: 'foo' })

 actually types in your input, this is not the single event fired over your DOM node, since each keystroke will dispatch an event, and the existing value of the input will affect its new value.

 methods, you are missing out on several other potentially important events the user is firing along the way. As the 

 recommend, your test should resemble how users interact with your code as much as possible. It doesn't seem using 

 follows this recommendation (although it should usually be enough).

For getting more realistic events dispatched like they would happen if a user interacts with the document, it's recommended to use 

; a companion library for Testing Library that simulates user interactions by dispatching the events that would happen if the interaction took place in a browser.

 methods are different since v14 and is not 100% compatible with this rule yet, so some details explained in this lesson may differ between v13 and v14.

 equivalent, we will be simulating the actual chain of DOM events that would be fired in the browser from the user interaction. With this ESLint rule, we want to encourage you to use 

 rule reports an error, you'll see the following message:

---
title: prefer-user-event rule
description: Understanding the errors reported by the rule `prefer-user-event`
isPublicLesson: false
---

# `prefer-user-event` rule

:::tip

This rule is compatible with all Testing Library frameworks supported by this plugin.

:::

## Understanding the rule

The Testing Library frameworks provide a built-in utility to fire DOM events over the elements of your UI: `fireEvent`.

The methods from `fireEvent` will create the desired event and dispatch it on the given DOM node exactly as you tell it and just those, even if those exact events had never been dispatched in a real interaction in a browser.

Consider `fireEvent.click` as an example. It works properly for most situations when you simply want to test what happens in your UI when your element is clicked. However, when the _user_ actually clicks your element, these are the events that are usually fired (in order):

1.  mouse over: `fireEvent.mouseOver(element)`
2.  mouse move: `fireEvent.mouseMove(element)`
3.  mouse down: `fireEvent.mouseDown(element)`
4.  focus: `element.focus()` (if the element is focusable)
5.  mouse up: `fireEvent.mouseUp(element)`
6.  click: `fireEvent.click(element)`

Another example would be testing how an input handles the values typed. This is usually performed with `fireEvent.keyDown`, where you need to pass the element to dispatch the event and the actual event object to be dispatched: `fireEvent.keyDown(element, target: { value: 'foo' })`. When the _user_ actually types in your input, this is not the single event fired over your DOM node, since each keystroke will dispatch an event, and the existing value of the input will affect its new value.

As you can see, by simply using `fireEvent` methods, you are missing out on several other potentially important events the user is firing along the way. As the [Testing Library Guiding Principles](https://testing-library.com/docs/guiding-principles/) recommend, your test should resemble how users interact with your code as much as possible. It doesn't seem using `fireEvent` follows this recommendation (although it should usually be enough).

For getting more realistic events dispatched like they would happen if a user interacts with the document, it's recommended to use `user-event`; a companion library for Testing Library that simulates user interactions by dispatching the events that would happen if the interaction took place in a browser.

:::info

We are using `@testing-library/user-event` v13 for this lesson. The `userEvent` methods are different since v14 and is not 100% compatible with this rule yet, so some details explained in this lesson may differ between v13 and v14.

:::

By using `userEvent.click(element)` or `userEvent.type(element, 'foo')` instead of their `fireEvent` equivalent, we will be simulating the actual chain of DOM events that would be fired in the browser from the user interaction. With this ESLint rule, we want to encourage you to use `userEvent` over `fireEvent` when possible.

When `prefer-user-event` rule reports an error, you'll see the following message:

> Prefer using {user-event-methods} over fireEvent.{fire-event-method}

## How to fix the errors reported

In order to follow the best practices encouraged by this rule, we need to use `userEvent` over `fireEvent`. This doesn't necessarily mean changing one `fireEvent` method to a `userEvent` one, although most of the time it should be as simple as that.

In this example, we are firing two events:

```javascript { actualFilename=protected/demo-app/src/lesson/example.test.jsx endChar=581 endLine=22 startChar=0 startLine=1 url=https&#x3A;//gitlab.com/fullstackio/books/master-writing-testing-library-tests-using-eslint-plugin-testing-library/module_02/lesson_02.11/protected/demo-app/src/lesson/example.test.jsx }
import React from 'react'
import { render, screen, fireEvent } from '@testing-library/react'
import { App } from '../App'

it('should render a basic demo', () => {
  render(<App />)

  const button = screen.getByRole('button', { name: 'Count is: 0' })
  fireEvent.click(button)
  expect(button).toHaveTextContent('Count is: 1')

  const resetInput = screen.getByLabelText(
    /write "reset" and hit enter to reset all the counts/i,
  )

  fireEvent.keyDown(resetInput, {
    code: 'Enter',
    target: { value: 'reset' },
  })
  expect(button).toHaveTextContent('Count is: 0')
})
```

We basically want to test the click in the counter, and the reset of the counter by entering a specific text in the input:

-   The `fireEvent.click` should be just replaced by `userEvent.click`
-   The `fireEvent.keyDown` gets more complicated though. By firing that event, we are doing two things in the same event; assigning the "reset" value to the input, and simulating the "Enter" key being pressed. A user would never do that at once, so we need to split this `fireEvent` method into two user interactions:

Understanding the errors reported by the rule `prefer-user-event`