chai, enzyme, jest, mocha, and react-testing-library are foundational tools in the JavaScript testing ecosystem, but they serve different purposes. jest and mocha are test runners that execute test suites and report results. chai is an assertion library used to write expressive test expectations. enzyme (now deprecated) and react-testing-library are React-specific utilities for rendering and interacting with components during tests. Modern best practices favor jest as a zero-config runner with built-in assertions and mocking, paired with react-testing-library for user-centric React testing, while mocha and chai remain viable for non-React or highly customized testing setups.
Testing Tools in the JavaScript Ecosystem: chai, enzyme, jest, mocha, and react-testing-library
Choosing the right testing tools is critical for building maintainable, reliable frontend applications. The landscape includes assertion libraries, test runners, and React-specific utilities — each serving distinct roles. Let’s break down how chai, enzyme, jest, mocha, and react-testing-library fit into modern testing workflows, with real code examples and practical guidance.
🧪 Core Responsibilities: What Each Package Actually Does
It’s important to understand that these packages don’t all solve the same problem. Some are test runners, others are assertion libraries, and a few are React component testing utilities.
jestis a full-featured test runner with built-in assertions, mocking, and snapshot testing.mochais a flexible test runner that requires separate assertion and mocking libraries.chaiis an assertion library often paired withmocha(or other runners).enzymeis a utility for testing React components by shallow rendering or full DOM rendering (now largely deprecated).react-testing-libraryis a React testing utility focused on user-centric component interaction.
You typically combine a runner (jest or mocha) with an assertion library (chai or Jest’s built-ins) and optionally a React testing helper (react-testing-library or, historically, enzyme).
🔍 Assertion Styles: BDD vs TDD vs Built-In
How you write your expectations depends heavily on your chosen assertion library.
chai supports both BDD (expect, should) and TDD (assert) styles:
// chai with expect (BDD)
expect(result).to.equal(42);
expect(list).to.include('item');
// chai with assert (TDD)
assert.equal(result, 42);
assert.include(list, 'item');
jest has its own built-in assertion API, inspired by Jasmine:
// jest built-in
expect(result).toBe(42);
expect(list).toContain('item');
mocha doesn’t include assertions — you must bring your own (like chai):
// mocha + chai
const { expect } = require('chai');
describe('example', () => {
it('works', () => {
expect(add(2, 2)).to.equal(4);
});
});
react-testing-library doesn’t provide assertions — it returns DOM elements that you assert on using your test framework’s matcher (e.g., Jest’s expect):
// react-testing-library + jest
const { getByText } = render(<Button label="Click me" />);
expect(getByText('Click me')).toBeInTheDocument();
enzyme included its own assertion helpers via .find(), .text(), etc., but still required an external assertion library:
// enzyme + chai (deprecated pattern)
const wrapper = shallow(<Button label="Submit" />);
expect(wrapper.find('button').text()).to.equal('Submit');
⚠️ Important: As of February 2023, Enzyme is officially unmaintained. The team recommends migrating to
react-testing-library. Do not use Enzyme in new projects.
🏗️ Test Runner Capabilities: Setup, Mocking, and Watch Mode
jest includes everything out of the box:
- Zero-config setup for most JavaScript projects
- Built-in mocking (
jest.fn(),jest.mock()) - Snapshot testing
- Interactive watch mode with filtering
- Code coverage reporting
// jest mock example
jest.mock('./api');
api.fetchUser.mockResolvedValue({ id: 1, name: 'Alice' });
mocha is minimal by design. You add what you need:
- Requires separate libraries for mocking (e.g.,
sinon) - No built-in snapshot or coverage — needs Istanbul/nyc
- Watch mode available via CLI flag (
--watch)
// mocha + sinon mock
const sinon = require('sinon');
const apiStub = sinon.stub(api, 'fetchUser').resolves({ id: 1 });
Both runners support hooks like beforeEach, afterAll, etc., but jest’s global setup is more streamlined for frontend apps.
🧩 React Component Testing: Implementation vs Behavior
This is where philosophy matters most.
enzyme encouraged testing implementation details:
// enzyme (discouraged today)
const wrapper = shallow(<MyComponent />);
expect(wrapper.state('loading')).to.be.true;
expect(wrapper.find('ChildComponent').props().value).to.equal('test');
This tightly couples tests to internal component structure, making refactors painful.
react-testing-library promotes testing like a user:
// react-testing-library (recommended)
const { getByRole, getByLabelText } = render(<LoginForm />);
const emailInput = getByLabelText('Email');
fireEvent.change(emailInput, { target: { value: 'test@example.com' } });
const submitButton = getByRole('button', { name: /submit/i });
fireEvent.click(submitButton);
await waitFor(() => expect(screen.getByText('Success!')).toBeInTheDocument());
You interact with elements the way users do — by role, label, or text — not by class names or component hierarchy.
🔄 Integration Patterns: How These Tools Work Together
In practice, you’ll see two dominant stacks:
Stack 1: Jest + react-testing-library (Modern Standard)
- Runner:
jest - Assertions: Built-in
expect - React Testing:
@testing-library/react
✅ Recommended for new React projects. Fully supported, aligned with React team guidance.
// Full example
import { render, screen, fireEvent } from '@testing-library/react';
import MyForm from './MyForm';
test('submits form with valid input', async () => {
render(<MyForm />);
fireEvent.change(screen.getByLabelText('Name'), { target: { value: 'John' } });
fireEvent.click(screen.getByRole('button', { name: /save/i }));
expect(await screen.findByText('Saved!')).toBeInTheDocument();
});
Stack 2: Mocha + Chai + Sinon + (Legacy React Tooling)
- Runner:
mocha - Assertions:
chai - Mocks:
sinon - React: Historically
enzyme, now migrated toreact-testing-library
✅ Still viable for non-React projects or legacy systems where Jest isn’t feasible.
// mocha + chai + react-testing-library
const { expect } = require('chai');
const { render, screen } = require('@testing-library/react');
describe('Header', () => {
it('displays logo', () => {
render(<Header />);
expect(screen.getByAltText('Company logo')).to.exist;
});
});
Note: Even with mocha, you can (and should) use react-testing-library instead of enzyme.
🛑 Deprecation Reality Check
As confirmed by Enzyme’s official GitHub README:
“Enzyme is no longer under active development. We recommend using React Testing Library instead.”
The project hasn’t kept pace with React 16.3+ features like hooks, suspense, or concurrent rendering. Tests written with Enzyme may pass while the actual app breaks in production due to mismatched rendering models.
📊 Decision Matrix: When to Use What
| Scenario | Recommended Stack |
|---|---|
| New React app | jest + react-testing-library |
| Non-React JS project needing flexibility | mocha + chai + sinon |
| Legacy React app using Enzyme | Migrate to react-testing-library; keep jest or mocha as runner |
| Need advanced mocking or snapshot testing | jest (built-in) |
| Prefer explicit control over test toolchain | mocha + pluggable ecosystem |
💡 Final Guidance
- For React projects: Use
jestandreact-testing-library. This combo is endorsed by the React team and scales well from simple components to complex user flows. - For vanilla JS or Node.js:
mocha+chairemains a solid, modular choice — especially if you want to avoid Jest’s opinionated defaults. - Never start a new project with
enzyme. The maintenance gap makes it a liability. chaiis unnecessary withjest— Jest’s assertions are sufficient and better integrated.
Testing isn’t just about verifying code — it’s about enabling confident refactoring and catching regressions early. Choose tools that encourage testing what users experience, not how your components are built internally. That mindset shift, supported by react-testing-library and jest, pays dividends as your app grows.
- chai:
Choose
chaiif you're using a test runner likemochaortapethat doesn't include its own assertion library, and you prefer expressive BDD/TDD syntax (expect,should, orassert). It’s unnecessary when usingjest, which provides a robust built-in assertion API. Avoid addingchaisolely for style preferences — consistency with your existing toolchain matters more. - jest:
Choose
jestfor most new JavaScript or TypeScript projects, especially React apps. It provides zero-config setup, built-in mocking, snapshot testing, code coverage, and a powerful watch mode out of the box. Its integrated assertion library reduces dependency bloat, and its compatibility withreact-testing-librarymakes it the de facto standard for modern frontend testing. - mocha:
Choose
mochawhen you need maximum flexibility in your testing stack, such as in non-React Node.js applications or environments where Jest’s opinionated defaults (e.g., automatic mocking, JSDOM setup) are undesirable. Pair it withchaifor assertions andsinonfor spies/stubs. Be prepared to configure coverage, mocking, and module resolution manually. - enzyme:
Do not choose
enzymefor new projects. It is officially unmaintained as of 2023 and incompatible with modern React features like hooks, suspense, and concurrent rendering. If you maintain a legacy codebase usingenzyme, prioritize migration toreact-testing-library. Its focus on implementation details (e.g., state, props, shallow rendering) leads to brittle tests that hinder refactoring. - react-testing-library:
Choose
react-testing-libraryfor all new React component tests. It encourages testing components the way users interact with them — by querying accessible roles, labels, and text — rather than implementation details. It works seamlessly withjestbut also integrates withmocha. Adopt it even in legacy projects to improve test reliability and enable safe refactoring.
chai
Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.
For more information or to download plugins, view the documentation.
What is Chai?
Chai is an assertion library, similar to Node's built-in assert. It makes testing much easier by giving you lots of assertions you can run against your code.
Installation
Node.js
chai is available on npm. To install it, type:
$ npm install --save-dev chai
Browsers
You can also use it within the browser; install via npm and use the index.js file found within the download. For example:
<script src="./node_modules/chai/index.js" type="module"></script>
Usage
Import the library in your code, and then pick one of the styles you'd like to use - either assert, expect or should:
import { assert } from 'chai'; // Using Assert style
import { expect } from 'chai'; // Using Expect style
import { should } from 'chai'; // Using Should style
Register the chai testing style globally
import 'chai/register-assert'; // Using Assert style
import 'chai/register-expect'; // Using Expect style
import 'chai/register-should'; // Using Should style
Import assertion styles as local variables
import { assert } from 'chai'; // Using Assert style
import { expect } from 'chai'; // Using Expect style
import { should } from 'chai'; // Using Should style
should(); // Modifies `Object.prototype`
import { expect, use } from 'chai'; // Creates local variables `expect` and `use`; useful for plugin use
Usage with Mocha
mocha spec.js --require chai/register-assert.js # Using Assert style
mocha spec.js --require chai/register-expect.js # Using Expect style
mocha spec.js --require chai/register-should.js # Using Should style
Read more about these styles in our docs.
Plugins
Chai offers a robust Plugin architecture for extending Chai's assertions and interfaces.
- Need a plugin? View the official plugin list.
- Want to build a plugin? Read the plugin api documentation.
- Have a plugin and want it listed? Simply add the following keywords to your package.json:
chai-pluginbrowserif your plugin works in the browser as well as Node.jsbrowser-onlyif your plugin does not work with Node.js
Related Projects
- chaijs / chai-docs: The chaijs.com website source code.
- chaijs / assertion-error: Custom
Errorconstructor thrown upon an assertion failing. - chaijs / deep-eql: Improved deep equality testing for Node.js and the browser.
- chaijs / check-error: Error comparison and information related utility for Node.js and the browser.
- chaijs / loupe: Inspect utility for Node.js and browsers.
- chaijs / pathval: Object value retrieval given a string path.
Contributing
Thank you very much for considering to contribute!
Please make sure you follow our Code Of Conduct and we also strongly recommend reading our Contributing Guide.
Here are a few issues other contributors frequently ran into when opening pull requests:
- Please do not commit changes to the
chai.jsbuild. We do it once per release. - Before pushing your commits, please make sure you rebase them.
Contributors
Please see the full Contributors Graph for our list of contributors.
Core Contributors
Feel free to reach out to any of the core contributors with your questions or concerns. We will do our best to respond in a timely manner.
Core Contributor Alumni
This project would not be what it is without the contributions from our prior core contributors, for whom we are forever grateful:
