@testing-library/angular vs @testing-library/react vs @testing-library/vue vs jest-dom

Building Component Testing Stacks Across Frameworks

@testing-library/react, @testing-library/vue, and @testing-library/angular are framework-specific rendering utilities that allow developers to test components in isolation using DOM queries. jest-dom is a companion library that provides custom Jest matchers to assert state on DOM nodes. Together, they form a complete testing stack where the framework package renders the component and jest-dom validates the output.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package	Downloads	Stars	Size	Issues	Publish	License
Package	Downloads	Stars	Size	Issues	Publish	License
@testing-library/angular	0	791	188 kB	6	14 days ago	MIT
@testing-library/react	0	19,655	340 kB	82	a month ago	MIT
@testing-library/vue	0	1,122	30.5 kB	38	2 years ago	MIT
jest-dom	0	-	-	-	7 years ago	-

Component Testing Stacks: React vs Vue vs Angular vs Jest-Dom

Testing frontend components requires two main steps: rendering the component into a test environment and asserting that the output matches expectations. The @testing-library family splits these concerns. The framework-specific packages handle rendering, while jest-dom handles assertions. Let's break down how they work together and where they differ.

🖥️ Rendering Components: Framework Specifics

Each framework has its own way of mounting components to the DOM. The testing libraries wrap these mechanisms to provide a consistent API.

@testing-library/react uses React's createRoot or render internally.

It manages React's strict mode and automatic cleanup.
You pass JSX directly to the render function.

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

render(<Button label="Submit" />);
expect(screen.getByText('Submit')).toBeInTheDocument();

@testing-library/vue works with Vue component objects or SFCs.

It handles Vue's reactivity system and lifecycle hooks.
You pass the component definition and optional props.

// @testing-library/vue
import { render, screen } from '@testing-library/vue';
import Button from './Button.vue';

render(Button, { props: { label: 'Submit' } });
expect(screen.getByText('Submit')).toBeInTheDocument();

@testing-library/angular integrates with Angular's TestBed.

It manages Angular's change detection and dependency injection.
You pass the component class and often need to declare imports.

// @testing-library/angular
import { render, screen } from '@testing-library/angular';
import { ButtonComponent } from './button.component';

await render(ButtonComponent, { componentProperties: { label: 'Submit' } });
expect(screen.getByText('Submit')).toBeInTheDocument();

✅ Making Assertions: The Role of Jest-Dom

While the rendering libraries query the DOM, they do not provide custom assertion messages by default. jest-dom fills this gap by extending Jest's expect.

jest-dom adds matchers specifically for DOM nodes.

It works with all three framework libraries above.
It provides clearer error messages than standard equality checks.
You must import it once in your test setup file.

// jest-dom setup (e.g., in setupTests.js)
import '@testing-library/jest-dom';

// Usage in any test file
import { screen } from '@testing-library/react';

const button = screen.getByRole('button');
expect(button).toBeInTheDocument();
expect(button).not.toBeDisabled();
expect(button).toHaveTextContent('Submit');

Without jest-dom, you would rely on generic matchers that are less descriptive.

// Without jest-dom (less clear)
expect(button).toBeTruthy();
expect(button.disabled).toBe(false);
expect(button.textContent).toContain('Submit');

🔍 Querying the DOM: A Shared Language

One of the biggest benefits of this stack is the shared querying API. Regardless of the framework, you query the rendered output the same way.

All Packages support screen and query methods.

getByRole is preferred for accessibility.
getByText works for simple text content.
findBy variants handle async loading states.

// React
const { screen } = require('@testing-library/react');
screen.getByRole('button');

// Vue
const { screen } = require('@testing-library/vue');
screen.getByRole('button');

// Angular
const { screen } = require('@testing-library/angular');
screen.getByRole('button');

This consistency means learning the testing API once applies to all three frameworks. You do not need to relearn how to find elements when switching projects.

🛠️ Setup and Configuration Differences

Setting up the test environment varies slightly due to framework requirements.

@testing-library/react requires a DOM environment.

Usually configured via jsdom in Jest or Vitest.
Minimal config needed beyond the test runner.

// jest.config.js for React
module.exports = {
  testEnvironment: 'jsdom',
  setupFilesAfterEnv: ['<rootDir>/src/setupTests.js']
};

@testing-library/vue needs Vue specific globals.

May require installing Vue test utils internally.
Handles automatic cleanup of Vue instances.

// jest.config.js for Vue
module.exports = {
  testEnvironment: 'jsdom',
  setupFilesAfterEnv: ['<rootDir>/src/setupTests.js']
};

@testing-library/angular requires Angular TestBed config.

Needs to import BrowserModule or similar.
Often requires async setup due to Angular compilation.

// jest.config.js for Angular
module.exports = {
  preset: 'jest-preset-angular',
  setupFilesAfterEnv: ['<rootDir>/src/setupTests.ts']
};

jest-dom requires a global import.

Must be imported before any tests run.
Typically added to the setupFilesAfterEnv array.

// src/setupTests.js (used by all)
import '@testing-library/jest-dom';

📊 Summary: Core Responsibilities

Package	Primary Role	Framework	Assertion Matchers
`@testing-library/react`	Render React Components	React	No (needs jest-dom)
`@testing-library/vue`	Render Vue Components	Vue	No (needs jest-dom)
`@testing-library/angular`	Render Angular Components	Angular	No (needs jest-dom)
`jest-dom`	DOM Assertions	Any	Yes (extends expect)

💡 The Big Picture

The choice between @testing-library/react, @testing-library/vue, and @testing-library/angular is not a choice at all — it is dictated by your framework. You cannot use the React library to test a Vue component. The real decision is whether to include jest-dom in your stack.

Include jest-dom if you want readable test failures and standard DOM matchers. It is the industry standard for Testing Library setups.

Skip jest-dom only if you are using a different assertion library like Chai or Vitest's built-in matchers that already cover DOM needs.

Final Thought: These tools work best as a team. Pick the renderer that matches your framework, add jest-dom for assertions, and rely on the shared querying API to keep your tests consistent across your organization.

How to Choose: @testing-library/angular vs @testing-library/react vs @testing-library/vue vs jest-dom

@testing-library/angular:
Choose this package if your project is built with Angular. It handles Angular's change detection and zone.js requirements. It is necessary to render Angular components within the TestBed utility structure.
@testing-library/react:
Choose this package if your project is built with React. It is the official testing utility maintained by the Testing Library team for React components. It handles React-specific rendering concerns like act warnings and hooks cleanup automatically.
@testing-library/vue:
Choose this package if your project is built with Vue.js. It integrates with Vue's reactivity system and lifecycle hooks. It is required to properly render Vue components and trigger updates in a test environment.
jest-dom:
Choose this package if you are using Jest as your test runner and want readable DOM assertions. It works with any of the framework-specific libraries above. It is not a renderer but adds matchers like toBeInTheDocument to your expect statements.

Popular Comparisons

@testing-library/angular

@testing-library/react

@testing-library/vue

jest-dom

README for @testing-library/angular

@testing-library/angular

Simple and complete Angular testing utilities that encourage good testing practices.

Read The Docs | Edit the docs

downloads

TestingJavaScript.com Learn the smart, efficient way to test any JavaScript application.

The problem

You want to write maintainable tests for your Angular components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

This solution

The @testing-library/angular is a very lightweight solution for testing Angular components. It provides light utility functions on top of Angular and @testing-library/dom, in a way that encourages better testing practices. Its primary guiding principle is:

The more your tests resemble the way your software is used, the more confidence they can give you.

Zoneless support

For zoneless applications, Angular Testing Library provides a dedicated slim entry point:

import { render } from '@testing-library/angular/zoneless';

A schematic is available to migrate existing tests:

ng generate @testing-library/angular:migrate-to-zoneless

Example

counter.component.ts

@Component({
  selector: 'atl-counter',
  template: `
    <span>{{ hello() }}</span>
    <button (click)="decrement()">-</button>
    <span>Current Count: {{ counter() }}</span>
    <button (click)="increment()">+</button>
  `,
})
export class CounterComponent {
  counter = model(0);
  hello = input('Hi', { alias: 'greeting' });

  increment() {
    this.counter.set(this.counter() + 1);
  }

  decrement() {
    this.counter.set(this.counter() - 1);
  }
}

counter.component.spec.ts

import { render, screen, fireEvent, aliasedInput } from '@testing-library/angular';
import { CounterComponent } from './counter.component';

describe('Counter', () => {
  it('should render counter', async () => {
    await render(CounterComponent, {
      inputs: {
        counter: 5,
        // aliases need to be specified this way
        ...aliasedInput('greeting', 'Hello Alias!'),
      },
    });

    expect(screen.getByText('Current Count: 5')).toBeVisible();
    expect(screen.getByText('Hello Alias!')).toBeVisible();
  });

  it('should increment the counter on click', async () => {
    await render(CounterComponent, { inputs: { counter: 5 } });

    const incrementButton = screen.getByRole('button', { name: '+' });
    fireEvent.click(incrementButton);

    expect(screen.getByText('Current Count: 6')).toBeVisible();
  });
});

See more examples

Installation

This module is distributed via npm which is bundled with node and should be installed as one of your project's devDependencies. Starting from ATL version 17, you also need to install @testing-library/dom:

npm install --save-dev @testing-library/angular @testing-library/dom

Or, you can use the ng add command. This sets up your project to use Angular Testing Library, which also includes the installation of @testing-library/dom.

ng add @testing-library/angular

You may also be interested in installing jest-dom so you can use the custom jest matchers.

Docs

Version compatibility

Angular	Angular Testing Library
22.x	19.x
21.x	19.x
20.x	18.x, 17.x, 16.x, 15.x, 14.x, 13.x
19.x	17.x, 16.x, 15.x, 14.x, 13.x
18.x	17.x, 16.x, 15.x, 14.x, 13.x
17.x	17.x, 16.x, 15.x, 14.x, 13.x
16.x	14.x, 13.x
>= 15.1	14.x, 13.x
< 15.1	12.x, 11.x
14.x	12.x, 11.x

Guiding Principles

The more your tests resemble the way your software is used, the more confidence they can give you.

We try to only expose methods and utilities that encourage you to write tests that closely resemble how your Angular components are used.

Utilities are included in this project based on the following guiding principles:

If it relates to rendering components, it deals with DOM nodes rather than component instances, nor should it encourage dealing with component instances.
It should be generally useful for testing individual Angular components or full Angular applications.
Utility implementations and APIs should be simple and flexible.

At the end of the day, what we want is for this library to be pretty light-weight, simple, and understandable.

Contributors

Thanks goes to these people (emoji key):

_{Tim Deschryver} 💻 📖 🚇 ⚠️	_{Michaël De Boey} 📖	_{Ignacio Le Fluk} 💻 ⚠️	_{Tamás Szabó} 💻	_{Gregor Woiwode} 💻	_{Toni Villena} 🐛 💻 📖 ⚠️	_ShPelles 📖
_Miluoshi 💻 ⚠️	_{Nick McCurdy} 📖	_{Srinivasan Sekar} 📖	_Bitcollage 📖	_{Emil Sundin} 💻	_Ombrax 💻	_{Rafael Santana} 💻 ⚠️ 🐛
_{Benjamin Blackwood} 📖 ⚠️	_{Gustavo Porto} 📖	_{Bo Vandersteene} 💻	_Janek 💻 ⚠️	_{Gleb Irovich} 💻 ⚠️	_Arjen 💻 🚧	_{Suguru Inatomi} 💻 🤔
_{Amit Miran} 🚇	_{Jan-Willem Willebrands} 💻	_Sandro 💻 🐛	_{Michael Westphal} 💻 ⚠️	_Lukas 💻	_{Matan Borenkraout} 🚧	_mleimer 📖 ⚠️
_MeIr 🐛 ⚠️	_{John Dengis} 💻 ⚠️	_{Rokas Brazdžionis} 💻	_{Mateus Duraes} 💻	_{Josh Joseph} 💻 ⚠️	_{Torsten Knauf} 🚧	_{antischematic} 🐛 🤔
_{Florian Pabst} 💻	_{Mark Goho} 🚧 📖	_{Jan-Willem Baart} 💻 ⚠️	_{S. Mumenthaler} 💻 ⚠️	_{Andrei Alecu} 💻 🤔 📖	_{Daniel Ramírez Barrientos} 💻	_{Mahdi Lazraq} 💻 ⚠️
_{Arthur Petrie} 💻	_{Fabien Dehopré} 💻	_{Jamie Vereecken} 💻	_Christian24 💻 👀	_{Michal Štrajt} 💻 🐛	_{J. Degand} 💻	_{Maksim Popov} 💻
_MattijsE 💻	_{Jonas Kuske} 💻	_{Ryan Diehl} 💻	_{Jeevan Mahesha} 📖