ReactFoo Mumbai

I’ve been using React for almost 5 years, but I hadn’t written a single test till quite recently. I always felt that testing is difficult, time consuming and mostly unnecessary. But after trying it, I realized that it’s actually really really easy to test React & Redux applications, and requires almost zero setup to get started. It’s totally worth the investment!

Besides, it doesn’t have to be “all or nothing”. You can test specific parts of application logic in isolation, and save yourself from hours of mindless debugging. Moreover, writing tests also acts as a forcing function to write modular, encapsulated and testable code.

This talk should be accessible to most developers familiar with React JS and Redux.

Outline

I plan to spend about 5 minutes talking about each of the following topics:

• Why, when and what to test?
• Testing React+Redux apps
• Writing testable code
• Testing Redux reducers and action creators
• Testing presentational components using snapshots
• Mocking network requests and testing asynchronous code
• Putting it all together

The talk will involve some live coding and testing.

Following is a detailed outline of the talk:

Introduction to Unit Testing in React

(7-8 minutes)

Unit testing refers to the testing of individual components or ‘units’ of an application in isolation, to validate that each unit is working as expected, and identify errors and bugs before shipping the code to production. Unit testing is also helpful while refactoring code, to ensure that no unexpected changes or bugs are introduced during the refactor.

The first step for testing is to ensure that the codebase is cleanly separated into various parts like Style Guide presentational components, reducers, action creators, containers, pages etc., we can easily test each part in isolation. We’ll use Jest as our testing framework, since it is automatically installed with create-react-app and is really easy to use.

Tests can be executed by running the following command from the root directory of a React application:

npm run test

Tests are run in watch mode by default, which means they are re-executed every time source files are modified and saved. This makes it really easy to write code and monitor the test results side-by-side.

<Some simple live coding examples of testing>

Unit Testing Reducer & Action Creators

(5 minutes)

Since reducers and action creators are just plain functions, we can test them in isolation by providing some sample arguments to the functions, and asserting that the outputs are as expected.

<Some simple live coding examples of testing>

Unit Testing Async (Thunk) Action Creators

(7-8 minutes)

Unit testing reducers and standard action creators in isolation is simple, since they are pure functions. However, the same isn’t true for asynchronous action creators, for two reasons:

They are not pure functions i.e. they have side-effects e.g. making network requests or accessing local storage. Depending on the network can make the tests slow and flaky. Also, it’s impractical to maintain a server simply for running unit tests.
They contain asynchronous code i.e. they have promises and callbacks which are invoked in the future, long after the original function has returned.
To address the first issue, we’ll create mock functions to replace the network calls, and the use those for testing.

<Some simple live coding examples of mocking & testing using mocks>

Snapshot Testing of Presentational Components

(7-8 minutes)

Snapshot testing is used to ensure that our UI does not change in unexpected ways. The basic idea is to capture a sample snapshot of the DOM tree rendered by a React component and compare against it whenever there is a code change.

<Some simple live coding examples of snapshot testing>

Unit Testing Business Logic & Miscellaneous Code

(5 minutes)

Apart from reducers, action creators, presentational components, container components etc. our application also contains several miscellaneous and utility functions, which are used all over the application. They are generally placed in util directories adjacent to containers, reducers, pages etc.

Utility functions are generally pure functions, without side effects like making network requests, accessing local storage, modifying global variables etc. This makes it really easy to test them in isolation, just like reducers and action creators.

Because pure functions are easy to test, it is a good idea to extract parts of business logic into small, standalone utility functions, instead of writing the logic inline within React components. It also promotes code reuse.

<Some simple live coding examples of testing>

Closing thoughts and Q&A - 5 minutes

Requirements

Prerequisites:

• React JS
• Redux

Speaker bio

I’ve been using React JS since 2013, and React Native since its initial release, so I’m well versed with the tools, libraries, community best practices etc. As a part of my consulting and freelance work, I have helped several teams adopt React JS and related tools & technologies (React Router, Redux, Webpack etc.) for large enterprise-scale applications.

I’ve also created several open source projects related to React JS and React Native, the most popular of which is ‘react-native-dialogs’ which has 400+ stars on Github and is used by 2500+ developers every month (more at npmjs.com/~aakashns ) . Apart from this, I also blog frequently about React/React Native and related topics at medium.com/@aakashns .

https://www.linkedin.com/in/aakashns/

Links

• https://redux.js.org/recipes/writing-tests
• https://reactjs.org/docs/test-utils.html