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.

This rule applies to some Testing Library utils which were deprecated in Testing Library frameworks a few major versions ago, but have been removed in recent versions, so please make sure you check the 

 to find more about which Testing Library frameworks and versions are applied.

In the latest versions of Testing Library frameworks, we have the 

 util to wait until some expectation passes, but there used to be other async utilities available in older versions:

 combines all their use cases into a single async util. This rule will report the usages of those three deprecated (and now removed) methods.

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

---
title: prefer-wait-for rule
description: Understanding the errors reported by the rule `prefer-wait-for`
isPublicLesson: false
---

# `prefer-wait-for` rule

:::tip

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

:::

## Understanding the rule

This rule applies to some Testing Library utils which were deprecated in Testing Library frameworks a few major versions ago, but have been removed in recent versions, so please make sure you check the ["When it should be enabled" section](#when-it-should-be-enabled) to find more about which Testing Library frameworks and versions are applied.

In the latest versions of Testing Library frameworks, we have the `waitFor` util to wait until some expectation passes, but there used to be other async utilities available in older versions:

-   `wait`
-   `waitForElement`
-   `waitForDomChange`

These 3 utils were deprecated since `waitFor` combines all their use cases into a single async util. This rule will report the usages of those three deprecated (and now removed) methods.

When `prefer-wait-for` rule reports an error, you'll see the following messages:

> `{deprecated-async-util-name}` is deprecated in favour of `waitFor`
>
> import `waitFor` instead of deprecated async utils

## How to fix the errors reported

Since those three utils were replaced by `waitFor`, that's the actual fix to the problems reported by this rule; just use `waitFor` instead.

There is an exception for the `waitForElement` method. This was usually combined with a `get*` query to find elements asynchronously. By using `waitFor` instead, we would have a combination of `waitFor` + `get*` query, which is exactly what `find*` query covers! So if you have a `waitForElement` + `get*` query, this can be directly replaced by a `find*` query. If for whatever reason you can't use a `find*` query, then `waitFor` should be a replacement for `waitForElement`.

In the following example, you can see a couple of errors reported for deprecated async utils:

```javascript { actualFilename=protected/demo-app/src/lesson/example.test.jsx endChar=440 endLine=17 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.12/protected/demo-app/src/lesson/example.test.jsx }
import React from 'react'
import { render, screen, wait, waitForElement } from '@testing-library/react'
import { App } from '../App'

Understanding the errors reported by the rule `prefer-wait-for`