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 only compatible with React, Angular, and Vue Testing Library frameworks.

Most of the Testing Library frameworks available are built on top of DOM Testing Library. This means that some utils you use from your Testing Library framework (e.g. React Testing Library) are wrappers around DOM Testing Library ones, enhancing part of the functionality to be fully compatible with the library used to build your UI. Other utils are just re-exported, so you don't have to guess if you need to import an util from DOM Testing Library or the other framework; you can always stick to the latter.

However, it may be the case that you would still import Testing Library utils from 

 by mistake, or even your code editor auto imports them from there. This is dangerous since you might be losing the enhancement that the other Testing Library framework adds on top of DOM Testing Library, causing unexpected behaviors.

To avoid importing Testing Library utils from the wrong module, this rule will report all the imports found from 

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

import from DOM Testing Library is restricted, import from 

The errors reported by this rule are pretty straightforward to get fixed. In the following example, we are importing 

import React from 'react'
import { screen } from '@testing-library/dom'
import { render } from '@testing-library/react'

import { App } from '../App'

it('should render a basic demo', () => {
  render(<App />)
  expect(screen.getByText('Hello Parcel + React!')).toBeInTheDocument()
})

The rule reports such import as a linting violation. We only need to move the utils imported from 

---
title: no-dom-import rule
description: Understanding the errors reported by the rule `no-dom-import`
isPublicLesson: false
---

# `no-dom-import` rule

:::caution

This rule is only compatible with React, Angular, and Vue Testing Library frameworks.

:::

## Understanding the rule

Most of the Testing Library frameworks available are built on top of DOM Testing Library. This means that some utils you use from your Testing Library framework (e.g. React Testing Library) are wrappers around DOM Testing Library ones, enhancing part of the functionality to be fully compatible with the library used to build your UI. Other utils are just re-exported, so you don't have to guess if you need to import an util from DOM Testing Library or the other framework; you can always stick to the latter.

However, it may be the case that you would still import Testing Library utils from `@testing-library/dom` by mistake, or even your code editor auto imports them from there. This is dangerous since you might be losing the enhancement that the other Testing Library framework adds on top of DOM Testing Library, causing unexpected behaviors.

To avoid importing Testing Library utils from the wrong module, this rule will report all the imports found from `@testing-library/dom`. When `no-dom-import` rule reports an error, you'll see the following message:

> import from DOM Testing Library is restricted, import from `{ framework }` instead

## How to fix the errors reported

The errors reported by this rule are pretty straightforward to get fixed. In the following example, we are importing `screen` from `@testing-library/dom`:

```javascript { actualFilename=protected/demo-app/src/lesson/example.test.jsx endChar=285 endLine=11 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.01/protected/demo-app/src/lesson/example.test.jsx }
import React from 'react'
import { screen } from '@testing-library/dom'
import { render } from '@testing-library/react'

import { App } from '../App'

it('should render a basic demo', () => {
  render(<App />)
  expect(screen.getByText('Hello Parcel + React!')).toBeInTheDocument()
})
```

The rule reports such import as a linting violation. We only need to move the utils imported from `@testing-library/dom` to our Testing Library framework (`@testing-library/react` in our example):

Understanding the errors reported by the rule `no-dom-import`