Skip to content

Use react testing library instead of enzyme #2298

@simonseyock

Description

@simonseyock

The react testing library enables to test components a lot like users would use them. Also it does not need full applications, it can just render single components and test them as if they were in a real page.

It is still quite atomic and can therefore replace the common tests formerly written in enzyme. It follows another philosophy though, that I find quite reasonable (see below). It enables to work with newer features of redux, for example the useSelector hook.

This text is from the react testing library page about enzyme:

The primary purpose of the React Testing Library is to give you confidence by testing your components in the way the user will use them. Users don't care what happens behind the scenes. They just see and interact with the output. So, instead of accessing the components' internal API, or evaluating the state, you'll get more confidence by writing your tests based on the component output.

React Testing Library aims to solve the problem that many developers face when writing tests with Enzyme which allows (and encourages) developers to test implementation details. Tests which do this ultimately prevent you from modifying and refactoring the component without changing the test. As a result, the tests slowed down your development speed and productivity, since every small change requires rewriting some part of your tests, even if the change you made does not affect the component's output.

Re-writing your tests in React Testing library is worthwhile, because you're trading tests that slow you down for tests that give you more confidence and increase your productivity in the long run.

https://testing-library.com/docs/react-testing-library/migrate-from-enzym

Guide

Find tests

  1. What user actions need to be done to test the functionality that was formerly tested with enzyme?
  2. Look in the styleguide, is there e2e functionality that could be tested additionally?
  3. Look at the props of the component, is there something that should be tested as well?

Write tests

  1. Use getRole / getText / etc. to retrieve elements. Try to be as semantic as possible. Look at the errors of these functions. They help a lot. If needed add role tags, this helps accessibility of the page as well (see point 5 for antd problems). Do only use query... methods if you want to test if an element is not available.
  2. Use @testing-library/jest-dom (i.e. expect(input).toHaveValue('some value'); or expect(element).toBeVisible();) for better test output.
  3. Use jest-fetch-mock to mock fetch
  4. Use waitFor or findRole / findText / etc. to work with async effects. They help with not wrapped in act(...) and performed state update on unmounted component warnings. These should all be resolved and can sometimes even occur only if multiple tests are run after each other. For special cases there exists TestUtil.setTimeout, try to avoid it.
  5. If testing with external frontend components (like antd Autocomplete) it is sometimes not possible to select elements semantically if they are not marked correctly. For this case I created the file Util/antdTestQueries to create the appropriate query / get / find selectors. This should only be the last resort.

Read more

Status

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions