Hello again!

Today we’re going to discuss testing, specifically unit testing. Our work for today is to cover our previous app (tutorial #1) with unit tests using Jest and Enzyme. I advise to clone the sample app from GitHub, before proceeding.

The content of this article is valid to react and react-native.

Testing introduction

This is the simplified version of the testing pyramid presented by Google from the opening keynote of the 2014 Google Test Automation Conference:

The pyramid base is made of unit tests. It’s an extensive layer testing your features in isolation. These tests are usually small, but in great quantity, to cover every single feature. They are fast and reliable, and often one failed test can give you valuable information to find that bug you’ve been looking for, before sending it to production.

In the middle layer we have integration tests. Usually these tests depend on external systems like a database or the network, and cover more than one component.

End-to-End tests are the ultimate defense against bugs, they test the entire system and the flow of your app, as a real user will. You can think of E2E testing like a brainless quality assurance test. The goal is to find crashes and bugs on usage flows. Because of this, an E2E test needs to run on an emulator or a real phone.

Usually as you move up the pyramid, the test number gets smaller but the test itself gets larger.

What do we want to test?

Using redux to manage state forces our app logic to be connected with redux store by actions, reducers or middlewares. Those are the kinds of things we can unit-test.

Today we’re going to focus on testing our redux actions creators, reducers and components behaviors.

Before that, there are two concepts and one library I must introduce. Enzyme will help us test component render outputs. Snapshot is the tool we are going to use and Jest Mocks are going to be helpful to stub some external dependencies. Let’s talk a bit on those.

Snapshot Testing

Jest snapshots are a very useful tool when it comes to preventing unexpected changes in your UI/functions.

When you’re making a snapshot test, you’re simply saying that you want the component or function output. With that, you can assess its behavior.

The first time a snapshot test is run, Jest will create a snapshot file with the output. Whenever you change your code and the tests start failing (test output not matching snapshot) you have to generate the snapshot file again and check if the output reflects your recent changes.

To generate new snapshots you must run:

Let’s see an example!

As you can see in this small example, we have a function and its corresponding test. We are telling Jest that we are expecting the output of ‘sum’ function to match snapshot. The snapshot gives the return value of our test matcher parameter, in this case 9, which is totally correct!

Enzyme

From the docs: ‘Enzyme is a JavaScript Testing utility for React that makes it easier to assert, manipulate, and traverse your React Components’ output.’

Enzyme’s API focus on different types of component render, but for today’s exercise we will be using only shallow render. This is useful to test the component as a unit. With this technique we can assert that my component contains, for example, other child components. We can even change the state of the rendered component dynamically and expect the changes we want to see.

Combining it with snapshot testing and a small lib called enzyme-to-json, we can ask enzyme to render the component and output it to a snapshot file, and then we can assess things about it.

Mocks

Most of the time the code you’re trying to test has an external dependency, our unit tests are supposed to isolate the code we want to test, and that’s where the value of mocks appear. Mocks are used to stub functions or dependencies with mock data.

This two links can give you enough information to start: