Book Image

Mastering React Test-Driven Development

By : Daniel Irvine
Book Image

Mastering React Test-Driven Development

By: Daniel Irvine

Overview of this book

Many programmers are aware of TDD but struggle to apply it beyond basic examples. This book teaches how to build complex, real-world applications using Test-Driven Development (TDD). It takes a first principles approach to the TDD process using plain Jest and includes test-driving the integration of libraries including React Router, Redux, and Relay (GraphQL). Readers will practice systematic refactoring while building out their own test framework, gaining a deep understanding of TDD tools and techniques. They will learn how to test-drive features such as client- and server-side form validation, data filtering and searching, navigation and user workflow, undo/redo, animation, LocalStorage access, WebSocket communication, and querying GraphQL endpoints. The book covers refactoring codebases to use the React Router and Redux libraries. via TDD. Redux is explored in depth, with reducers, middleware, sagas, and connected React components. The book also covers acceptance testing using Cucumber and Puppeteer. The book is fully up to date with React 16.9 and has in-depth coverage of hooks and the ‘act’ test helper.
Table of Contents (21 chapters)
Free Chapter
1
Section 1: First Principles of TDD
6
Section 2: Building a Single-Page Application
12
Section 3: Interactivity
16
Section 4: Acceptance Testing with BDD

Manual testing

Manual testing means starting your application and using it. It takes up a lot of time, not just because you'll be actually using the application, but also because it takes time to get test environments set up and primed with the relevant test data.

For this reason, it's important to avoid manual testing where possible. There are, however, times when it's necessary, as we'll discover in this section.

Since you're engaging with your own creative work, you are undoubtedly interested to find out how it performs. You should certainly take the time to do this, but think of it as downtime and a chance to relax, rather than a formal part of your development process.

There is always a temptation to manually test software after each feature is complete, just to verify that it actually works. If you have to do this a lot, consider how much confidence...