chai-dom vs enzyme vs jest-dom vs react-testing-library
Frontend Testing Utilities for React and DOM Assertions
Search packages..
chai-domenzymejest-domreact-testing-librarySimilar Packages:

Frontend Testing Utilities for React and DOM Assertions

chai-dom, enzyme, jest-dom, and react-testing-library are JavaScript libraries that support testing user interfaces, particularly in React applications. They provide utilities for rendering components, simulating user interactions, and asserting on DOM structure or behavior. While all aim to improve test reliability and developer experience, they differ significantly in philosophy, API design, maintenance status, and integration with modern testing ecosystems.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
chai-dom07768 kB14a year agoMIT
enzyme019,840-2816 years agoMIT
jest-dom0---7 years ago-
react-testing-library0---7 years ago-

Frontend Testing Tools Compared: chai-dom, enzyme, jest-dom, and react-testing-library

When writing tests for React applications, developers rely on libraries to render components, simulate interactions, and verify outcomes. The four packages under review serve overlapping but distinct roles in this workflow. Understanding their scope, compatibility, and current viability is essential for making sound architectural decisions.

🧪 Core Responsibilities: What Each Package Actually Does

It’s critical to recognize that these tools don’t all solve the same problem:

  • react-testing-library renders React components into a DOM environment and provides utilities to query and interact with them.
  • jest-dom adds custom Jest matchers to make DOM assertions more semantic and robust.
  • chai-dom offers similar DOM assertions but for the Chai assertion library, typically used outside Jest.
  • enzyme (deprecated) was a full-featured React testing utility that included rendering, querying, and lifecycle control.

Let’s examine how they approach common testing tasks.

🖼️ Rendering Components and Querying the DOM

react-testing-library is built around the principle of testing what the user sees. It renders components into a container and exposes queries like getByText, getByRole, etc.

// react-testing-library
import { render, screen } from '@testing-library/react';
import Greeting from './Greeting';

test('displays hello message', () => {
  render(<Greeting name="Alice" />);
  expect(screen.getByText('Hello, Alice!')).toBeInTheDocument();
});

enzyme provided multiple rendering modes (shallow, mount, render). Shallow rendering was popular for isolating components, but it bypassed React’s actual rendering behavior.

// enzyme (deprecated)
import { shallow } from 'enzyme';
import Greeting from './Greeting';

test('displays hello message', () => {
  const wrapper = shallow(<Greeting name="Alice" />);
  expect(wrapper.text()).toEqual('Hello, Alice!');
});

jest-dom and chai-dom do not render anything. They only enhance assertions on DOM nodes that have already been rendered by another tool.

// jest-dom used alongside react-testing-library
import { render } from '@testing-library/react';
import '@testing-library/jest-dom';

const { container } = render(<button disabled>Click me</button>);
expect(container.querySelector('button')).toBeDisabled();

// chai-dom used with jsdom and mocha
import chai from 'chai';
import chaiDom from 'chai-dom';
chai.use(chaiDom);

const button = document.createElement('button');
button.disabled = true;
expect(button).to.be.disabled;

âś… Writing Readable Assertions

jest-dom shines in Jest environments by offering intuitive matchers:

// jest-dom
expect(element).toBeInTheDocument();
expect(element).toBeVisible();
expect(element).toHaveClass('active');
expect(input).toHaveValue('test');

chai-dom provides equivalent capabilities for Chai users:

// chai-dom
expect(element).to.be.inDocument;
expect(element).to.be.visible;
expect(element).to.have.class('active');
expect(input).to.have.value('test');

Note that neither defines how the element is obtained — that’s left to your test setup (e.g., via jsdom, react-testing-library, or manual DOM manipulation).

enzyme required manual traversal or assertions using its wrapper API:

// enzyme
expect(wrapper.find('button').prop('disabled')).toBe(true);
expect(wrapper.contains('Hello')).toBe(true);

These assertions often probed component internals rather than user-facing output.

⚠️ Maintenance and Compatibility Status

As of 2024:

  • enzyme is officially deprecated. Its GitHub repository states: "Enzyme is no longer being actively maintained... We recommend using React Testing Library instead." It does not support React 18+ features reliably and breaks with concurrent rendering.
  • react-testing-library, jest-dom, and chai-dom are actively maintained and compatible with modern React.

If you’re starting a new project, do not use Enzyme. If you maintain a legacy codebase using Enzyme, plan a migration to React Testing Library.

đź”— Typical Testing Stack Integrations

In practice, these tools are rarely used in isolation:

  • Jest + React Testing Library + jest-dom is the dominant stack for React testing today:

    // Full modern test
import { render, screen, fireEvent } from '@testing-library/react';
import '@testing-library/jest-dom';
import Button from './Button';

test('calls onClick when clicked', () => {
  const handleClick = vi.fn();
  render(<Button onClick={handleClick} />);
  fireEvent.click(screen.getByRole('button'));
  expect(handleClick).toHaveBeenCalledTimes(1);
});

  • Mocha + Chai + chai-dom + jsdom is a viable alternative for non-Jest environments:

    // Mocha/Chai setup
import { JSDOM } from 'jsdom';
import chai from 'chai';
import chaiDom from 'chai-dom';
chai.use(chaiDom);

const dom = new JSDOM('<!DOCTYPE html><div id="root"></div>');
global.document = dom.window.document;
global.window = dom.window;

// Then render your component (e.g., via ReactDOM) and assert with chai-dom

enzyme historically paired with Mocha or Jest but required adapters for each React version, adding maintenance overhead.

🛠️ Handling User Interactions

Only react-testing-library provides built-in utilities for simulating realistic user events via fireEvent or userEvent:

// react-testing-library
fireEvent.change(input, { target: { value: 'new text' } });
// or better:
import userEvent from '@testing-library/user-event';
await userEvent.type(input, 'hello');

enzyme offered methods like .simulate('click'), but these triggered React synthetic events directly, not real DOM events, leading to gaps between test and real behavior.

jest-dom and chai-dom have no interaction APIs — they are assertion-only.

đź“Ś Summary Table

PackageRenders Components?Simulates Events?Provides DOM Assertions?Test Runner Agnostic?Maintenance Status
react-testing-library✅✅ (fireEvent)❌ (use with jest-dom)✅Actively maintained
jest-dom❌❌✅❌ (Jest-only)Actively maintained
chai-dom❌❌✅✅ (Chai-compatible)Actively maintained
enzyme✅✅ (limited)❌✅Deprecated

đź’ˇ Final Guidance

  • For new React projects: Use react-testing-library + jest-dom with Jest. This combination follows React team recommendations and focuses tests on user-visible behavior.
  • If you must use Mocha/Chai: Pair react-testing-library (for rendering and events) with chai-dom (for assertions), using jsdom as your DOM environment.
  • Avoid enzyme entirely in new codebases. Its design conflicts with modern React, and migration paths to React Testing Library are well-documented.

The goal of testing isn’t to verify that your component’s internal state is correct — it’s to ensure users can achieve their goals. The tools that encourage this mindset (react-testing-library and its assertion companions) lead to more resilient, meaningful tests.

How to Choose: chai-dom vs enzyme vs jest-dom vs react-testing-library

  • chai-dom:

    Choose chai-dom if you're already using the Chai assertion library and need DOM-specific assertions (like checking element visibility or attributes) within a non-Jest test runner such as Mocha. It extends Chai’s BDD/TDD syntax with DOM helpers but doesn’t handle component rendering or user events — it only enhances assertions on existing DOM nodes.

  • enzyme:

    Do not choose enzyme for new projects. The library is officially deprecated as of 2023, with its maintainers recommending migration to React Testing Library. While Enzyme offered powerful APIs for shallow rendering and direct component instance inspection, it relies on internal React implementation details that are incompatible with modern React features like hooks and concurrent rendering.

  • jest-dom:

    Choose jest-dom when writing tests with Jest and you need expressive, readable assertions on DOM elements (e.g., toBeInTheDocument(), toBeDisabled()). It extends Jest’s expect with custom matchers focused solely on DOM state and does not provide tools for rendering components or simulating user interactions — it complements libraries like React Testing Library.

  • react-testing-library:

    Choose react-testing-library for new React projects because it encourages testing components as users interact with them — by querying the rendered DOM and firing real-like events. It integrates seamlessly with Jest (especially via @testing-library/jest-dom for assertions) and aligns with React’s current best practices, avoiding implementation details in favor of observable behavior.

Similar Npm Packages to enzyme

enzyme is a popular testing utility for React that makes it easier to assert, manipulate, and traverse React component output. Developed by Airbnb, enzyme provides a robust API that allows developers to test React components in a variety of ways, including shallow rendering, full DOM rendering, and static rendering. This flexibility makes it a valuable tool for unit testing and integration testing in React applications. However, there are several alternatives available that also cater to testing needs in the JavaScript ecosystem. Here are a few notable alternatives:

  • chai is an assertion library for Node.js and browsers that can be paired with any testing framework. It provides a rich set of assertions for writing tests, making it easier to express expectations in a readable manner. While chai is not specifically designed for React, it can be used alongside other testing libraries like Mocha or Jest to enhance the testing experience. If you prefer a BDD-style assertion library that integrates well with various testing frameworks, chai is a solid choice.

  • jest is a widely-used testing framework developed by Facebook, particularly popular in the React community. It comes with a built-in assertion library and supports features like mocking, snapshot testing, and code coverage analysis. Jest is known for its ease of use and zero-config setup, making it an excellent choice for testing React applications. Many developers opt for Jest as their primary testing framework due to its comprehensive features and seamless integration with React.

  • mocha is a flexible testing framework for Node.js and browsers that allows developers to write tests in a variety of styles, including BDD and TDD. Mocha does not come with an assertion library by default, but it can be easily paired with libraries like chai for assertions. While it requires a bit more setup compared to Jest, Mocha's flexibility and extensive ecosystem make it a popular choice for many developers looking for a customizable testing solution.

  • react-testing-library is a library that focuses on testing React components in a way that resembles how users interact with them. It encourages better testing practices by promoting tests that are more aligned with user behavior rather than implementation details. React Testing Library is often used in conjunction with Jest, making it a powerful combination for testing React applications. If your goal is to write tests that prioritize user experience and interaction, React Testing Library is an excellent alternative to enzyme.

For a comprehensive comparison of these testing libraries, check out the following link: Comparing chai vs enzyme vs jest vs mocha vs react-testing-library.

Similar Npm Packages to jest-dom

jest-dom is a popular testing utility for Jest, specifically designed to enhance the experience of testing DOM nodes in React applications. It provides a set of custom matchers that extend Jest's built-in assertions, allowing developers to write more expressive and readable tests for their components. With jest-dom, you can easily assert the presence, state, and attributes of DOM elements, making your tests more intuitive and easier to maintain. While jest-dom is a powerful tool for testing, there are several alternatives available in the React testing ecosystem. Here are a few notable ones:

  • chai-dom is an extension for the Chai assertion library that adds custom matchers for asserting on DOM elements. It provides a similar functionality to jest-dom, enabling developers to write more readable assertions for their DOM elements. If you are already using Chai for your testing framework, chai-dom is a great choice to enhance your DOM assertions and improve the overall readability of your tests.
  • enzyme is a widely used testing utility for React that allows developers to manipulate, traverse, and simulate events on React components. While it provides a robust API for testing React components, it focuses more on component testing rather than direct DOM assertions. enzyme is particularly useful for shallow rendering and testing component behavior, making it a good choice if you need to test component logic in addition to DOM interactions.
  • react-testing-library is a popular library that encourages testing React components in a way that resembles how users interact with them. It promotes best practices by focusing on the behavior of components rather than their implementation details. While react-testing-library does not provide custom matchers like jest-dom, it works seamlessly with it, allowing you to write tests that are both user-centric and expressive.

To explore how these packages compare, check out the comparison: Comparing chai-dom vs enzyme vs jest-dom vs react-testing-library.

Similar Npm Packages to react-testing-library

react-testing-library is a popular testing utility for React applications that encourages good testing practices. It provides a simple and accessible API to render components and interact with them in a way that resembles how users would interact with the application. By focusing on testing components from the user's perspective, react-testing-library helps developers create more reliable and maintainable tests. While it is a powerful tool for testing React applications, there are several alternatives worth considering:

  • cypress is an end-to-end testing framework that allows developers to test their applications in a real browser environment. Unlike react-testing-library, which focuses on unit and integration testing of React components, cypress is designed for testing the entire application flow, including user interactions, API calls, and UI behavior. It provides a rich set of features, including time travel debugging, automatic waiting, and a powerful assertion library. If you need to test the complete user experience of your application, cypress is an excellent choice.
  • enzyme is another testing utility for React that allows developers to test components in isolation. It provides a more in-depth API for rendering components, allowing for shallow rendering, full DOM rendering, and static rendering. While enzyme is powerful and flexible, it encourages a different testing philosophy compared to react-testing-library, as it often focuses on the implementation details of components rather than user interactions. If you prefer a more detailed approach to testing and need to inspect component internals, enzyme may be the right tool for you.
  • jest-dom is an extension of the Jest testing framework that provides custom matchers for asserting on DOM nodes. It enhances the testing experience by allowing developers to write more expressive and readable assertions when testing React components. While jest-dom is not a standalone testing library, it complements react-testing-library by providing additional matchers that make it easier to assert on the state of the DOM. If you're already using Jest for your testing needs, incorporating jest-dom can improve the quality of your tests.

To explore how these testing libraries compare, check out the comparison: Comparing cypress vs enzyme vs jest-dom vs react-testing-library.

README for chai-dom

chai-dom

Build Status

chai-dom is an extension to the chai assertion library that provides a set of assertions when working with the DOM (specifically HTMLElement and NodeList)

Forked from chai-jquery to use for those of us freed of jQuery's baggage.

Assertions

attr(name[, value])

attribute(name[, value])

Assert that the HTMLElement has the given attribute, using getAttribute. Optionally, assert a particular value as well. The return value is available for chaining.

document.getElementById('header').should.have.attr('foo')
expect(document.querySelector('main article')).to.have.attribute('foo', 'bar')
expect(document.querySelector('main article')).to.have.attr('foo').match(/bar/)

class(className)

Assert that the HTMLElement has the given class, using classList.

document.getElementsByName('bar').should.have.class('foo')
expect(document.querySelector('main article')).to.have.class('foo')

Also accepts regex as argument.

document.getElementsByName('bar').should.have.class(/foo/)
expect(document.querySelector('main article')).to.have.class(/foo/)

id(id)

Assert that the HTMLElement has the given id.

document.querySelector('section').should.have.id('#main')
expect(document.querySelector('section')).to.have.id('foo')

html(html)

Assert that the html of the HTMLElement is equal to or contains the given html.

document.querySelector('.name').should.have.html('<em>John Doe</em>')
expect(document.querySelector('#title')).to.have.html('Chai Tea')

document.querySelector('.name').should.contain.html('<span>Doe</span>')
expect(document.querySelector('#title')).to.contain.html('<em>Tea</em>')

text(text)

Assert that the text of the HTMLElement or combined text of the NodeList is equal to or contains the given text, using textContent. Chaining flags:

trimmed - will trim the text before comparing
rendered - will use innerText when comparing

document.querySelector('.name').should.have.text('John Doe')
expect(document.querySelector('#title')).to.have.text('Chai Tea')
document.querySelectorAll('ul li').should.have.text('JohnJaneJessie')
document.querySelector('h1').should.have.trimmed.text('chai-tests')
expect(document.querySelector('article')).to.have.rendered.text('Chai Tea is great')

document.querySelector('.name').should.contain.text('John')
expect(document.querySelector('#title')).to.contain.text('Chai')
document.querySelectorAll('ul li').should.contain.text('Jane')

text(text[])

Assert that the textContent of the NodeList children deep equal those text, or when using the contains flag, all the text items are somewhere in the NodeList.

document.querySelectorAll('.name').should.have.text(['John Doe', 'Jane'])
expect(document.querySelectorAll('ul li')).to.have.text(['John', 'Jane', 'Jessie'])

document.querySelectorAll('.name').should.contain.text(['John Doe'])
expect(document.querySelectorAll('ul li')).to.contain.text(['John', 'Jessie'])

value(value)

Assert that the HTMLElement has the given value

document.querySelector('.name').should.have.value('John Doe')
expect(document.querySelector('input.year')).to.have.value('2012')

empty

Assert that the HTMLElement or NodeList has no child nodes. If the object asserted against is neither of those, the original implementation will be called.

document.querySelector('.empty').should.be.empty
expect(document.querySelector('section')).not.to.be.empty

length(n)

Assert that the HTMLElement or NodeList has exactly n child nodes. If the object asserted against is neither of those, the original implementation will be called.

document.querySelector('ul').should.have.length(2)
document.querySelector('li').should.have.length(2)
expect(document.querySelector('ul')).not.to.have.length(3)

exist

Assert that the NodeList is not empty. If the object asserted against is not a NodeList, the original implementation will be called.

document.querySelectorAll('dl dd').should.exist
expect(document.querySelectorAll('.nonexistent')).not.to.exist

match(selector)

Assert that the selection matches an HTMLElement or all elements in a NodeList, using matches. If the object asserted against is neither of those, the original implementation will be called.

Note matches is DOM Level 4, so you may need a polyfill for it.

document.querySelectorAll('input').should.match('[name="bar"]')
expect(document.getElementById('empty')).to.match('.disabled')

contain(selector or element)

Assert that the HTMLElement contains the given element, using querySelector for selector strings or using [contains][contains] for elements. If the object asserted against is not an HTMLElement, or if contain is not called as a function, the original implementation will be called.

document.querySelector('section').should.contain('ul.items')
document.querySelector('section').should.contain(document.querySelector('section div'))
expect(document.querySelector('#content')).to.contain('p')

descendant(selector or element)

Same as contain but changes the assertion subject to the matched element.

document.querySelector('section').should.have.descendant('ul').and.have.class('items')
document.querySelector('section').should.have.descendant(document.querySelector('section div'))
expect(document.querySelector('#content')).to.have.descendant('p')

descendants(selector)

Same as descendant but uses querySelectorAll instead of querySelector to change the assertion subject to a NodeList instead of a single element.

document.querySelector('section').should.have.descendants('ul li').and.have.length(3)

displayed

Assert that the HTMLElement is displayed (that display is not equal to "none"). If the element is attached to the body, it will call getComputedStyle; otherwise it will look at the inline display attribute.

document.querySelector('dl dd').should.be.displayed
expect(document.querySelector('.hidden')).not.to.be.displayed

visible

Assert that the HTMLElement is visible (that visibility is not equal to "hidden" or "collapse"). If the element is attached to the body, it will call getComputedStyle; otherwise it will look at the inline visibility attribute.

document.querySelector('dl dd').should.be.visible
expect(document.querySelector('.invisible')).not.to.be.visible

tagName(name)

Assert that the HTMLElement has the given tagName.

document.querySelector('.container').should.have.tagName('div')
expect(document.querySelector('.container')).not.to.have.tagName('span')

style(styleProp, styleValue)

Assert that the HTMLElement has the given style prop name value equal to a given value.

document.querySelector('.container').should.have.style('color', 'rgb(55, 66, 77)')
expect(document.querySelector('.container')).not.to.have.style('borderWidth', '3px')

focus

Assert that the HTMLElement has set focus.

document.querySelector('input').should.have.focus
expect(document.querySelector('.container')).not.to.have.focus

checked

Assert that the HTMLElement is an [HTMLInputElement][] with type of "checkbox" or "radio", and that its checked state is true or false.

document.querySelector('input').should.be.checked
expect(document.querySelector('.checkbox')).not.to.be.checked

Installation

npm

npm install chai-dom

bower

bower install chai-dom

Usage

CommonJS

var chai = require('chai')
chai.use(require('chai-dom'))

AMD

require(['chai', 'chai-dom'], function(chai, chaiDom) {
  chai.use(chaiDom)
})

Global

<script src="chai.js"></script>
<script src="chai-dom.js"></script>

Use the assertions with chai's expect or should assertions.

Contributing

To run the test suite, run npm install (requires Node.js to be installed on your system), and run npm test or open test/index.html in your web browser.

License

MIT License (see the LICENSE file)

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc, the official website for the npm registry. Note that npm is a registered trademark of npm, Inc. Please share your feedback via our GitHub repository. For more details, please refer to our Terms & Privacy.