Difference between enzyme, ReactTestUtils and react-testing-library
ReactTestUtils gives you the bare minimum to test a React component. I haven't seen it being used for big applications.
Enzyme and react-testing-library are both good libraries that give you all the tools you need to test your application. They have two different philosophies though.
Enzyme allows you to access the internal workings of your components. You can read and set the state, and you can mock children to make tests run faster.
On the other hand, react-testing-library doesn't give you any access to the implementation details. It renders the components and provides utility methods to interact with them. The idea is that you should communicate with your application in the same way a user would. So rather than set the state of a component you reproduce the actions a user would do to reach that state.
In my experience Enzyme is easier to grasp but in the long run, it's harder to maintain. react-testing-library forces you to write tests that are a bit more complex on average but it rewards you with higher confidence in your code.
Enzyme is intended for unit/integration testing. Its API was designed to test the implementation. It offers custom renderer that doesn't require DOM (for shallow rendering), behaves differently from React renderer and allows things that are important for unit testing but aren't possible or straightforward with default renderer, like synchronous state updates, shallow rendering, disabling lifecycle methods, etc.
react-testing-library is intended for blackbox integration/e2e tests. It uses React renderer and ReactTestUtils internally, requires real DOM because it's component's output that is asserted in tests, not internals. It doesn't provide facilities for isolated unit tests but it's possible to do this by mocking modules that contain component that need to be spied, mocked or stubbed by other means, notably jest.mock.
react-dom/test-utils and react-test-renderer contain a subset of functionality, Enzyme and react-testing-library were built upon them. API is scarce and requires to write boilerplate code or custom utility functions for full-grown testing. React officially promotes Enzyme and react-testing-library as better alternatives.
In Enzyme, we test the component using the state and props of the component. This generally means that the tests are brittle. Let's say we have already written tests for a component and it is running fine. But what if someone changes the variable name of a state or props in the component, then even if the functionality of the component hasn't changed, our test fails. This kind of behavior demonstrates the brittleness of the test.
Whereas in React Testing Library, we test the component from the user's perspective. Let's say we want to test a drop-down component, we won't test the component according to its state and props. Instead, we use the DOM elements to test it, just how the user interacts with it.
The primary purpose of React Testing Library is to increase confidence in your tests by testing your components in the way a user would use them. Users don't care what happens behind the scenes, they just see and interact with the output. Instead of accessing the components' internal APIs or evaluating their state, you'll get more confidence by writing your tests based on the component output.
At some point, React Testing Library became more widely used than Enzyme.
