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.

 util is an async method that runs the received callback many times until the corresponding expectation passes (i.e. it stops throwing an error). For this reason, 

 is intended for things that have a non-deterministic amount of time between the action you performed and the assertion passing.

Because of this, the callback can be called a non-deterministic number of times and frequency (it's called both on an interval and when there are DOM mutations). In other words; if you run side effects inside your 

 callback, they could run multiple times! It's dangerous to run those side effects many times since it would cause unexpected actions being duplicated, which would affect the final state of your assertions.

This rule will consider as invalid side effects to be placed within your 

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

---
title: no-wait-for-side-effects rule
description: Understanding the errors reported by the rule `no-wait-for-side-effects`
isPublicLesson: false
---

# `no-wait-for-side-effects` rule

:::tip

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

:::

## Understanding the rule

As we saw in the lesson for the rule, `no-wait-for-multiple-assertions`, the `waitFor` util is an async method that runs the received callback many times until the corresponding expectation passes (i.e. it stops throwing an error). For this reason, `waitFor` is intended for things that have a non-deterministic amount of time between the action you performed and the assertion passing.

Because of this, the callback can be called a non-deterministic number of times and frequency (it's called both on an interval and when there are DOM mutations). In other words; if you run side effects inside your `waitFor` callback, they could run multiple times! It's dangerous to run those side effects many times since it would cause unexpected actions being duplicated, which would affect the final state of your assertions.

This rule will consider as invalid side effects to be placed within your `waitFor` callback, the following methods:

-   `render`
-   `fireEvent` methods
-   `userEvent` methods

When `no-wait-for-side-effects` rule reports an error, you'll see the following message:

> Avoid using side effects within `waitFor` callback

## How to fix the errors reported

See the `waitFor` from this example, which is based again in our Pokémon demo app which fetches their data for the indicated ID:

```javascript { actualFilename=protected/demo-app/src/lesson/example.test.jsx endChar=715 endLine=26 startChar=0 startLine=1 url=https&#x3A;//gitlab.com/fullstackio/books/master-writing-testing-library-tests-using-eslint-plugin-testing-library/module_03/lesson_03.08/protected/demo-app/src/lesson/example.test.jsx }
import React from 'react'
import { render, screen, waitFor } from '@testing-library/react'
import { App } from '../App'
import userEvent from '@testing-library/user-event'
import { bulbasaur } from './fixtures'

const fetchMock = jest
  .fn()
  .mockResolvedValue({ ok: true, json: jest.fn().mockResolvedValue(bulbasaur) })

beforeEach(() => {
  global.fetch = fetchMock
})

it('should render the basic Pokémon info', async () => {
  render(<App />)

  const idInput = screen.getByLabelText('Pick one Pokémon by their ID')
  userEvent.type(idInput, '1')

  await waitFor(() => {
    userEvent.click(screen.getByRole('button', { name: 'Search' }))
    expect(screen.getAllByRole('listitem')).toHaveLength(2)
  })
})
```

Understanding the errors reported by the rule `no-wait-for-side-effects`