Testing Library

Testing Library

  • Docs
  • Recipes
  • Help
  • Blog

›Getting Started

Getting Started

  • Introduction
  • Guiding Principles
  • Using Fake Timers

Frameworks

    DOM Testing Library

    • Introduction
    • Install
    • Example
    • Setup
    • Queries
    • Firing Events
    • Async Utilities
    • Helpers
    • Configuration
    • FAQ
    • Cheatsheet

    React Testing Library

    • Introduction
    • Example
    • Setup
    • API
    • Migrate from Enzyme
    • FAQ
    • Cheatsheet

    Reason Testing Library

    • Introduction
    • Examples

    React Native Testing Library

    • Introduction
    • Example
    • Setup

    Vue Testing Library

    • Introduction
    • Examples
    • Setup
    • API
    • Cheatsheet
    • FAQ

    Marko Testing Library

    • Introduction
    • Setup
    • API

    Angular Testing Library

    • Introduction
    • Examples
    • API

    Preact Testing Library

    • Introduction
    • Example
    • API
    • Learn

    Svelte Testing Library

    • Introduction
    • Setup
    • Example
    • API
  • Cypress Testing Library
  • Puppeteer Testing Library
  • Testcafe Testing Library
  • Nightwatch Testing Library

Ecosystem

  • user-event
  • jest-dom
  • bs-jest-dom
  • jest-native
  • react-select-event
  • eslint-plugin-testing-library
  • eslint-plugin-jest-dom
  • riot-testing-library
  • jasmine-dom
Edit

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 web pages are used.

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

  1. If it relates to rendering components, then it should deal with DOM nodes rather than component instances, and it should not encourage dealing with component instances.
  2. It should be generally useful for testing the application components in the way the user would use it. We are making some trade-offs here because we're using a computer and often a simulated browser environment, but in general, utilities should encourage tests that use the components the way they're intended to be used.
  3. 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.

Last updated on 7/27/2019
← IntroductionUsing Fake Timers →
Testing Library
Docs
Getting StartedExamplesAPIHelp
Community
BlogStack OverflowDiscord
More
StarGitHubEdit Docs on GitHubHosted by Netlify
Copyright © 2018-2020 Kent C. Dodds and contributors