You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
What user actions need to be done to test the functionality that was formerly tested with enzyme?
Look in the styleguide, is there e2e functionality that could be tested additionally?
Look at the props of the component, is there something that should be tested as well?
Write tests
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.
Use @testing-library/jest-dom (i.e. expect(input).toHaveValue('some value'); or expect(element).toBeVisible();) for better test output.
Use jest-fetch-mock to mock fetch
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.
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.
This will get more relevant if we ever want to move to react >= 18. Enzyme does not support react >= 17 natively. For react 17 there existed an unofficial adapter, but the author already claimed that an adapter for react 18 will be to much work and it won't be written: https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl
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:
https://testing-library.com/docs/react-testing-library/migrate-from-enzym
Guide
Find tests
Write tests
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 addrole
tags, this helps accessibility of the page as well (see point 5 for antd problems). Do only usequery...
methods if you want to test if an element is not available.@testing-library/jest-dom
(i.e.expect(input).toHaveValue('some value');
orexpect(element).toBeVisible();
) for better test output.jest-fetch-mock
to mock fetchwaitFor
orfindRole
/findText
/ etc. to work with async effects. They help withnot wrapped in act(...)
andperformed 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 existsTestUtil.setTimeout
, try to avoid it.Autocomplete
) it is sometimes not possible to select elements semantically if they are not marked correctly. For this case I created the fileUtil/antdTestQueries
to create the appropriatequery
/get
/find
selectors. This should only be the last resort.Read more
act
issues: https://kentcdodds.com/blog/wrapping-react-use-state-with-type-scriptjest-fetch-mock
is mocking out the servers: https://kentcdodds.com/blog/stop-mocking-fetchStatus
The text was updated successfully, but these errors were encountered: