React 18 Migration: Refactor the React test suite to use React Testing Library #10184

tay1orjones · 2021-11-28T21:24:29Z

This issue is to track the refactoring of our React test suite to use React Testing Library.

Links and resources

How to find enzyme usages

The list below was generated by searching for enzyme within files having names containing our test suffix:

finding.enzyme.usages.mov

Please use the script to scaffold out new test files

Tasks

Give feedback

indented tasks (i.e. nested tasklist; support for this is coming!)
an empty task (i.e. - [ ] on a line by itself)
any empty new lines (before/after the tasklist or in between tasks)
duplicate issue/pr links
a draft task exceeds 512 characters

Please check the tasklists documentation for more information. 🔗 Feedback Discussion

Thank you for participating in the Private Beta ❤️

Use RTL for testing in DataTable/__tests__/DataTable-test.js #12665

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableExpandHeader-test.js #12666

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableExpandRow-test.js #12667

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableHeader-test.js #12668

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableSelectAll-test.js #12669

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableSelectRow-test.js #12670

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableToolbar-test.js #12671

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableToolbarContent-test.js #12672

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableToolbarMenu-test.js #12673

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTable/__tests__/TableToolbarSearch-test.js #12674

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in DataTableSkeleton/DataTableSkeleton-test.js #12675

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in RadioButtonGroup/next/RadioButtonGroup-test.js #11736

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖
Use RTL for testing in Search/Search-test.js #12153

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖
Remove SearchFilterButton #12155

role: dev 🤖
Use RTL for testing in SecondaryButton/SecondaryButton-test.js #12157

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖
Use RTL for testing in Select/Select-test.js #12158

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖
Use RTL for testing in SelectItem/SelectItem-test.js #12159

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖
Use RTL for testing in SelectItemGroup/SelectItemGroup-test.js #12160

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖
Use RTL for testing in Slider/Slider-test.js #12676

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in StructuredList-test.js #12663

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in Switch/Switch-test.js #12354

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖
Use RTL for testing in TextArea/TextArea-test.js #12677

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in TextInput/PasswordInput-test.js #12678

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in Tile/Tile-test.js #12679

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in TileGroup/TileGroup-test.js #12680

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in ToggleSmall/ToggleSmall-test.js #12681

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in Tooltip/Tooltip-test.js #12683

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in TooltipDefinition/TooltipDefinition-test.js #12682

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in TooltipIcon/TooltipIcon-test.js #12684

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in TreeView/TreeView-test.js #12685

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in internal ClickListener-test.js #12686

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in internal InnerClickListener-test.js #12687

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Use RTL for testing in internal Selection-test.js #12688

adopter: PAL package: @carbon/react role: dev 🤖 type: infrastructure 🤖 version: 11
Options

The text was updated successfully, but these errors were encountered:

tay1orjones · 2021-12-13T22:14:30Z

High level steps

Get familiar with the component, gather list of functionality/api to be tested
Comment out or rename existing tests
Include RTL imports
Create new structure based on details to be tested
Write tests
1. Render the component using render inside each it block
2. If applicable, find/query parts of a component to interact with
3. If applicable, interact with the component as a person would using userEvent
4. expect pieces of the component to be valid/correct using jest-dom matchers
Double check old tests have parity with new tests - did we leave anything out?
Validate that the test coverage from new tests is the same or higher as the old tests
PR and delete old tests

tay1orjones · 2021-12-13T22:41:16Z

Patterns

What should we test?

How does a person use the component?
- Click, hover
- Keyboard
  - focus
  - special keys relating to functionality - "esc to close"
- Opening/closing
- Selecting/de-selecting
- Toggling/disclosure
- Choosing from a list
How does a developer configure the component?
- Internal composition via children
- Potential common external composition? Like via Stack, Grid, etc?
- Callbacks/event handlers
- Refs
- i18n, translateById
- Other props
What else is part of the public API, or is depended upon by consumers?
- "Should place class name, data-testid on the outermost DOM node"
- "Should place forwardRef ref on the {intended element}" (input, label, outermost DOM node, etc)
- "Should place extra props on the {intended element}" (input, label, outermost DOM node, etc)
- ... what else?

Including RTL imports

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import '@testing-library/jest-dom';

cleanup from @testing-library/react should not be needed

Find parts of a component to interact with

Use Queries accessible to everyone
Prefer use of screen (defaults to document.body), rather than container

screen.getByRole('button', {name: /submit/i});

Avoid nesting while you're testing

render() in each it() block
- avoid hasty abstractions that use beforeEach, afterAll, etc. unless absolutely necessary (mocking or something similar)
The less describe() blocks the better

Avoid using .toMatchSnapshot()

Snapshots can provide a false sense of security since they're included in coverage reports
Higher possibility for false positive/negatives from future component changes
Remove them where possible and use a more thorough assertion instead
Percy VRT tests (not covered here) should cover the use case of ensuring a component's rendering/styling remains consistent

jnm2377 · 2021-12-14T19:44:04Z

These are some helpful things I used a lot to refactor the tabs tests to RTL

Examples of RTL tests in our components

Notification: https://github.com/carbon-design-system/carbon/pull/9494/files
v11 Tabs and Tab: https://github.com/carbon-design-system/carbon/pull/9722/files

Helpful docs

jest expect matchers (what we're expecting the test to look for)
RTL queries for selecting elements
RTL fireEvent for testing events (keyboard, click, etc)
RTL userEvent for testing events (keyboard, click, etc)
RTL cheatsheet

joshblack · 2021-12-15T18:56:04Z

Reference for old test code and how it could be updated

Renders as expected

About

This is a common pattern in the codebase that uses describe and it blocks to assert that a component renders or has the appropriate classes.

What does it look like

describe('ProgressIndicatorSkeleton', () => {
  describe('Renders as expected', () => {
    it('should have the expected classes', () => {
      const wrapper = mount(<ProgressIndicatorSkeleton />);
      expect(wrapper.hasClass(`${prefix}--skeleton`)).toEqual(true);
      expect(wrapper.hasClass(`${prefix}--progress`)).toEqual(true);
    });
  });
});

What about this is problematic

Tests that assert if a component renders are not needed as this would be caught by other tests that are asserting what happens as a user interacts with a component. For tests that assert on class names, these are not being tested in Jest and instead would be tested by appearance in VRT.

What to do about it

In most cases, you can remove these tests. If the test is for class names, replace it with a Visual Regression Test.

Component is mounted in an outer scope

About

In parts of our tests, you will see a component mounted outside of an it or beforeEach block. Often times, it will be at the top of a describe block

What does it look like

describe('SomeComponent', () => {
  const wrapper = mount(/* ... */);

  it('should do ...', () => {
    // Interacts with wrapper
  });
});

What about this is problematic

This outermost wrapper is inherently stateful. This means that if your tests are interacting with it, reading data from it, etc that you could run into flaky tests that depend on a specific ordering in order to pass. Overall, this leads to tests that are harder to debug when things go wrong.

What to do about it

You can move the wrapper into the it block directly if there are only several tests. For many tests that use the same setup, move the wrapper into a beforeEach with this pattern:

describe('SomeComponent', () => {
  let wrapper;

  beforeEach(() => {
    wrapper = mount(/* ... */);
  });

  it('should do ...', () => {
    // Interacts with wrapper
  });
});

This will ensure that the component is reset across test runs

`Wrapper#setState`

About

In enzyme tests, you will come across moments where wrapper.setState is called to change the internal state of a component.

What does it look like

it('should avoid updating state unless actual change in currentIndex is detected', () => {
  wrapper.setProps({ currentIndex: 1 });

  // 👇
  wrapper.setState({ currentIndex: 2 });
  // 👆

  wrapper.setProps({ currentIndex: 1 });
  expect(list.state().currentIndex).toEqual(2);
});

What about this is problematic

wrapper.setState allows you to change the internal state of a component without interacting with it in a way that the component intends for you to interact with it. As a result, you could end up with states that are invalid or unable to derive from a set of user interactions.

What to do about it

Replace wrapper.setState calls with actions. Actions are steps or procedures that a user can perform to change the state of a component.

From our example above, we are changing the state of a progress indicator to point to a different step. Instead of changing the internal state of the component, we could instead use an action to select a progress step as the current step.

userEvent.click(screen.getByLabelText('step-label'));

tay1orjones · 2021-12-15T22:48:15Z

We need to resurrect #4467 so that jest-dom matchers like toBeVisible will work.

joshblack · 2021-12-15T23:26:56Z

@tay1orjones PR for it over in: #10302 👍

tay1orjones · 2021-12-16T20:22:05Z

Where to place component composition (children) integration tests

For components that leverage composition of specific children, place composition integration tests in the parent component's test file.
As an example, Breadcrumb is intended to be augmented with BreadcrumbItem children. BreadcrumbItem also has specific conditions for when an OverflowMenu is passed as its children.
- Tests covering the full composition of Breadcrumb, BreadcrumbItems and the OverflowMenu should be placed in the Breadcrumb-test.js file.
- BreadcrumbItem tests testing individual props or functionality scoped to only the BreadcrumbItem should be placed in the `BreadcrumbItem-test.js file.

tay1orjones · 2021-12-16T20:31:25Z

Testing pseudo elements

jsdom does not currently support pseudo elements, so any component utilizing pseudo elements for core functionality can't really be fully tested through RTL.
We'll need to address these in two ways:
1. Test what we can in RTL. Typically this will result in asserting a particular element receives a specific class name.
2. Test this functionality in a browser-based environment via Cypress in an e2e test file. This can be deferred for now in the context of this refactor workstream.

joshblack · 2022-05-17T21:01:46Z

Test file archetypes

Snapshot tests

A snapshot test is a test file that only tests the structural output of a component. For example, expect(wrapper).toMatchSnapshot()

Example

import React from 'react';
import { BreadcrumbSkeleton } from '../';
import { mount } from 'enzyme';

describe('BreadcrumbSkeleton', () => {
  it('should render', () => {
    const wrapper = mount(<BreadcrumbSkeleton />);
    expect(wrapper).toMatchSnapshot();
  });
});

This test should be refactored to test the following applicable parts of a component:

Behavior (can the user interact with this component in some way?)
Configuration (can the developer change props on this component in some way?)

Refactor

import React from 'react';
import { BreadcrumbSkeleton } from '../';
import { render } from '@testing-library/react';

describe('BreadcrumbSkeleton', () => {
  it('should support a custom `className` prop on the outermost element', () => {
    const { container } = render(<BreadcrumbSkeleton className="test" />);
    expect(container.firstChild).toHaveClass('test');
  });

  it('should spread additional props on the outermost element', () => {
    const { container } = render(<BreadcrumbSkeleton data-testid="test" />);
    expect(container.firstChild).toHaveAttribute('test');
  });
});

TODO

Test files that have a mix of enzyme and testing-library
Shallow tests
Class assertions
- Prefix in outer scope
Wrapper not in test scope
Types of tests
- Structural (an attribute exists on a specific element, or an element is a specific role)
- Configuration (what happens when a user specifies a prop)
  - Make sure to test the default value
- Behavior
- Variants
  - These are variations of the base component that show up when a specific prop is changed (for example, type)
Naming conventions
- What should you name things in tests
- What should you avoid as names
  - Individual names
  - Popular names
  - Gendered words

Insights

Timing for specific components
- BreadscrumbSkeleton (sm)
- Button (md, lg)
Classname checks are fine, they're helpful for catching bugs

Checklist

Does the component have state?
Can a user interact with this in some way?
Does the component have props?
- What element do the props get applied to?
- Does the prop change the behavior of the component in some way?
Structure
- Imports are sorted
- Only one describe block in the test suite

When visiting a component
- If a component has a -test.e2e.js file, you can remove it
- If a test file imports cleanup from @testing-library/react you can remove it
- If a component has an accessibility describe block that is using aXe and AC, you can remove it

tay1orjones mentioned this issue Nov 28, 2021

Improve our React test suite #8143

Closed

tay1orjones changed the title ~~Refactor our existing React test suite to use React Testing Library~~ Refactor the React test suite to use React Testing Library Nov 28, 2021

tay1orjones changed the title ~~Refactor the React test suite to use React Testing Library~~ [Umbrella]: Refactor the React test suite to use React Testing Library Dec 10, 2021

tay1orjones added this to Design System Dec 10, 2021

tay1orjones moved this to ⏱ Backlog in Design System Dec 10, 2021

tay1orjones added the planning: umbrella Umbrella issues, surfaced in Projects views label Dec 10, 2021

tay1orjones changed the title ~~[Umbrella]: Refactor the React test suite to use React Testing Library~~ Refactor the React test suite to use React Testing Library Dec 10, 2021

tay1orjones moved this from ⏱ Backlog to 🏗 In Progress in Design System Dec 13, 2021

This comment was marked as outdated.

Sign in to view

abbeyhrt mentioned this issue Jan 14, 2022

test(react): update toggle tests to use react testing library #10452

Merged

tay1orjones moved this from 🏗 In Progress to ⏱ Backlog in Design System Jan 19, 2022

tay1orjones moved this from ⏱ Backlog to 🕵️‍♀️ Triage in Design System Feb 28, 2022

tay1orjones added this to the 2022 Q2 milestone Mar 15, 2022

tay1orjones moved this from 🕵️‍♀️ Triage to ⏱ Backlog in Design System May 9, 2022

tay1orjones mentioned this issue May 9, 2022

React 18 Migration: The Umbrella #11308

Closed

tay1orjones assigned tay1orjones and joshblack May 9, 2022

tay1orjones moved this from ⏱ Backlog to 🏗 In Progress in Design System May 9, 2022

carbon-automation bot added the status: waiting for author's response 💬 label May 17, 2022

joshblack removed the status: waiting for author's response 💬 label May 19, 2022

tay1orjones mentioned this issue Nov 16, 2022

Use RTL for testing in StructuredList-test.js #12663

Closed

5 tasks

tay1orjones modified the milestones: 2022 Q4, 2023 Q1 Jan 24, 2023

TannerS mentioned this issue Jan 25, 2023

test(TreeView): updated treeview test to use rtl #13025

Merged

tay1orjones mentioned this issue Mar 9, 2023

chore(test): remove enzyme #13316

Merged

kodiakhq bot closed this as completed in #13316 Mar 9, 2023

github-project-automation bot moved this from 🏗 In Progress to ✅ Done in Design System Mar 9, 2023

sstrubberg changed the title ~~Refactor the React test suite to use React Testing Library~~ React 18 Migration: Refactor the React test suite to use React Testing Library Apr 11, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

React 18 Migration: Refactor the React test suite to use React Testing Library #10184

React 18 Migration: Refactor the React test suite to use React Testing Library #10184

tay1orjones commented Nov 28, 2021 •

edited

Loading

Tasks

Initial wave of refactor (complete)

tay1orjones commented Dec 13, 2021 •

edited

Loading

tay1orjones commented Dec 13, 2021 •

edited

Loading

jnm2377 commented Dec 14, 2021

joshblack commented Dec 15, 2021 •

edited

Loading

tay1orjones commented Dec 15, 2021

joshblack commented Dec 15, 2021

This comment was marked as outdated.

This comment was marked as outdated.

tay1orjones commented Dec 16, 2021

tay1orjones commented Dec 16, 2021

joshblack commented May 17, 2022 •

edited

Loading

React 18 Migration: Refactor the React test suite to use React Testing Library #10184

React 18 Migration: Refactor the React test suite to use React Testing Library #10184

Comments

tay1orjones commented Nov 28, 2021 • edited Loading

Please use the script to scaffold out new test files

Tasks

Initial wave of refactor (complete)

tay1orjones commented Dec 13, 2021 • edited Loading

High level steps

tay1orjones commented Dec 13, 2021 • edited Loading

Patterns

What should we test?

Including RTL imports

Find parts of a component to interact with

Avoid nesting while you're testing

Avoid using .toMatchSnapshot()

jnm2377 commented Dec 14, 2021

Examples of RTL tests in our components

Helpful docs

joshblack commented Dec 15, 2021 • edited Loading

Renders as expected

Component is mounted in an outer scope

Wrapper#setState

tay1orjones commented Dec 15, 2021

joshblack commented Dec 15, 2021

This comment was marked as outdated.

This comment was marked as outdated.

tay1orjones commented Dec 16, 2021

Where to place component composition (children) integration tests

tay1orjones commented Dec 16, 2021

Testing pseudo elements

joshblack commented May 17, 2022 • edited Loading

Test file archetypes

Snapshot tests

Checklist

tay1orjones commented Nov 28, 2021 •

edited

Loading

tay1orjones commented Dec 13, 2021 •

edited

Loading

tay1orjones commented Dec 13, 2021 •

edited

Loading

joshblack commented Dec 15, 2021 •

edited

Loading

`Wrapper#setState`

joshblack commented May 17, 2022 •

edited

Loading