On this page
Testing the front-end was always a pain point for me. Enzyme was ok, Jest was better. Yet both had me digging into the internals of components, writing and changing code to make tests happy that made no material improvement to code quality. I could have 100% code coverage yet little trust in the actual tests.
Testing Library was the first approach to testing that enabled me to write tests in a productive way. The philosophy is:
The more your tests resemble the way your software is used, the more confidence they can give you
Testing Library is opinionated and only provides methods and utilities that encourage writing tests that closely resemble how your web pages are used. This means we avoid testing:
- The internal state of a component
- Internal methods of a component
- Lifecycle methods of a component
- Child components
By avoiding testing implementation details your tests become more maintainable because tests only break when your app breaks, not the implementation details. It also builds confidence as the tests interact with the app in the same way as end-users.
Supported Frameworks
The core of the library is the Dom Testing Library which provides a lightweight library for querying and interacting with DOM nodes (simulates with JSDOM/Jest or in the browser). However, it is framework agnostic and there is support for many frameworks including:
Final Thoughts
Testing Library is testing done right. It forces you to write tests in a maintainable way that give confidence in your app. I still believe there is a place for Jest unit tests on the backend but my philosophy is as Guillermo Rauch said: