Book Image

Simplify Testing with React Testing Library

By : Scottie Crump
Book Image

Simplify Testing with React Testing Library

By: Scottie Crump

Overview of this book

React Testing Library (RTL) is a lightweight and easy-to-use tool for testing the document object model (DOM) output of components. This book will show you how to use this modern, user-friendly tool to test React components, reducing the risk that your application will not work as expected in production. The book demonstrates code snippets that will allow you to implement RTL easily, helping you to understand the guiding principles of the DOM Testing Library to write tests from the perspective of the user. You'll explore the advantages of testing components from the perspective of individuals who will actually use your components, and use test-driven development (TDD) to drive the process of writing tests. As you advance, you'll discover how to add RTL to React projects, test components using the Context API, and also learn how to write user interface (UI) end-to-end tests using the popular Cypress library. Throughout this book, you’ll work with practical examples and useful explanations to be able to confidently create tests that don't break when changes are made. By the end of this React book, you will have learned all you need to be able to test React components confidently.
Table of Contents (10 chapters)

Chapter 3

  1. The user-event module closely resembles events that occur when users perform actions on the DOM, such as keydown and keyup events.
  2. MSW allows you to test components that make HTTP requests to APIs. This is done by intercepting the request before it reaches the internet and instead returns controllable mock data for testing.
  3. A mock function is a test double used to make assertions. For example, we can use a mock function to verify that a method is called when a user clicks a button.
  4. The risk is that substituting actual dependencies with mocked versions to test components doesn't allow you to test resulting behaviors when integrated with real production dependencies.
  5. This is an open-response question.
  6. Use a getBy* query when you expect an element to be present in the DOM's current state. Use a findBy* query when an element's presence depends on an asynchronous action that delays the time the element appears in the DOM. Use a queryBy*...