explaingit

testing-library/jest-dom

4,592JavaScriptAudience · developerComplexity · 2/5Setup · easy

TLDR

A library of 30+ extra assertion helpers for Jest and Vitest that make web UI tests more readable, write expect(button).toBeDisabled() instead of verbose manual DOM property checks.

Mindmap

mindmap
  root((jest-dom))
    What it does
      DOM assertions
      Test readability
      Accessibility checks
    Matchers
      Visibility and focus
      Form values
      ARIA roles
      CSS classes
    Tech stack
      JavaScript TypeScript
      Jest or Vitest
    Audience
      Frontend developers
      Test engineers
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Replace verbose DOM assertions in Jest or Vitest tests with readable one-liners like toBeVisible(), toBeDisabled(), and toHaveValue().

USE CASE 2

Check accessibility in tests by asserting on ARIA roles and accessible names with purpose-built matchers.

USE CASE 3

Use the companion ESLint plugin to automatically find and fix test files where a simpler jest-dom matcher could replace a generic assertion.

Tech stack

JavaScriptTypeScriptJestVitest

Getting it running

Difficulty · easy Time to first run · 5min

Import once in a Jest or Vitest setup file and all matchers are available globally across every test file.

In plain English

jest-dom is a JavaScript library that adds extra assertion helpers for testing web page content. When developers write automated tests for websites and web apps, they often need to check things like whether a button is disabled, whether a form field has the right value, whether some text appears on screen, or whether a particular CSS class is applied to an element. The standard Jest testing framework can do some of this, but the checks are verbose and repetitive. jest-dom adds around 30 purpose-built matchers that make these checks shorter and easier to read. For example, instead of writing a multi-step assertion to check whether an input field is disabled, you can write expect(element).toBeDisabled(). Instead of manually inspecting an element's text content with string matching, you can write expect(element).toHaveTextContent('hello'). There are matchers covering visibility, focus state, form values, CSS classes, HTML attributes, ARIA roles and accessibility names, checkbox state, and selection state, among others. The library works with Jest, Vitest, and any other test runner that uses a Jest-compatible assertion interface. You import it once in a setup file and it extends the expect object globally for all your tests. TypeScript types are included, so you get autocomplete in editors that support it. A companion ESLint plugin called eslint-plugin-jest-dom is also available. It checks your test files for cases where you are using a generic assertion when a more specific jest-dom matcher would be clearer, and can fix those automatically. The project is part of the Testing Library family of tools. The full README is longer than what was shown.

Copy-paste prompts

Prompt 1
I'm testing a React login form with React Testing Library and jest-dom. Write tests that check: the submit button is disabled when inputs are empty, an error message appears after a failed login, and the email field has the right placeholder text.
Prompt 2
Show me how to set up jest-dom in a Vitest project, what goes in the setup file and how do I configure vitest.config.ts to include it?
Prompt 3
I have a test that checks expect(element.textContent).toBe('Save'). Which jest-dom matcher should I use instead, and why is it better?
Prompt 4
Write jest-dom assertions to verify that a modal dialog is visible on screen, has the correct ARIA role, contains a close button that is not disabled, and has a specific accessible name.
Prompt 5
Set up eslint-plugin-jest-dom in my project and explain which rules to enable to catch cases where I'm using generic Jest matchers instead of specific jest-dom ones.
Open on GitHub → Explain another repo

← testing-library on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.