[SIP-56] Adopt React Testing Library for testing React components

[SIP] Proposal for adopting React Testing Library to test React components

Motivation

In Sept 2020, React Testing Library (RTL) has officially overtaken Enzyme as the most popular React testing library according to NPM downloads. While still widely popular, Enzyme has been running behind in catching up with all the latest React trends. It still doesn’t support the useEffect hook properly and has yet to officially support React 17.

Besides having a more promising future and a more active community, RTL also introduces a new way of thinking in writing tests. It encourages developers to focus on what users see, as opposed to how the components are implemented. Instead of checking component props and states with fine-grained internal APIs, you check the expected component outputs that are visible to the users. The official doc has more explanation.

We believe this is the right way to go and will help us write stabler tests more efficiently and with more confidence. With better support for simulated user events, we may even replace some Cypress tests with smaller scoped (and faster) React component tests.

Proposed Change

We propose to introduce React Testing Library to Superset’s frontend testing toolkit and gradually migrate Enzyme tests to it when possible.

New dependencies

@testing-library/react and @testing-library/jest-dom and a couple of related ESLint plugins will be added to superset-frontend and superset-ui’s dependencies.

Migration Plan and Compatibility

1. Add RTL to the codebase, try converting a couple of existing components to RTL. Hammer out global setups, etc.
2. Since there is no urgent need to migrate existing Enzyme tests, RTL and Enzyme will live side-by-side for as long as needed.
3. However, all new React component tests is recommended to be written with RTL to take advantage of its benefits described above.

Rejected Alternatives

• Keep status quo: the growing needs of better testing requires a better testing library.

[eschutho]

Makes sense to bring this up in the next meetup. I’m hearing a need to perhaps discuss standardization (cleaning up old code), testing approaches, and/or establishing a process around style guide. Let’s get some feedback around what people are feeling would be needed at this point to address any concerns left over.

[nytai]

I think it’s quite normal for a codebase that’s >5 years old to have a lot of accumulated patterns, especially one with as many contributors as superset. Sometimes introducing a new pattern is conflated with refactoring out all the old patterns. I don’t think anyone is suggesting migrating all enzyme tests to use RTL (or whatever the latest flavor is at the moment). React has been making quite a few changes to their API, I don’t think we should limiting our use there. Similarly, enzyme has fallen behind the curve, I don’t think we should continue to fight with the lib to get it to work with newer portions of the react api.

I have found myself fighting with enzyme, to get what should be simple tests to pass, more often than not (see how ubiquitous this util has become in test files). Therefore, consider this a big

+1

from me as I suspect writing tests will become far more enjoyable with RTL in the toolbox.