Unfortunately, it was not as simple as just running $ nvm use 18 and sailing into the sunset. Luckily, if you follow all the proper steps, you'll get past many significant hurdles and upgrade successfully. In this guide, I will share all the knowledge I wish I had known going into the process. The goal is to get your React application using Node 18+ and Jest 29+ while not making the treacherous upgrade to React Scripts 5.

If you can upgrade to React Scripts 5 (which is impractical for most real-world applications), I highly recommend that path instead. This is because the newest version of CRA fixes many issues with older dependencies, like the MD4 envelope or Babel process() return shapes, that we'll manually tackle in this tutorial. If you can upgrade to v5, then Node versions 18+ should work out of the box.

Unfortunately, going up to React Scripts 5 introduces many breaking changes, mostly due to the upgrade to Webpack 5. While many small/tutorial-level applications can upgrade fairly easily, any real-world application faces a steep uphill journey to upgrade.

If the React Scripts 5 upgrade approach doesn't work for you, you can follow what I've written below on making the Node upgrade work while still staying on React Scripts 4. At the end of this page, I've written a small note about my journey trying the v5 upgrade.

Everyone's upgrade journey will vary, especially considering the Jenga of npm dependencies and the relative lack of maintenance of Create React App's React Scripts in recent years.

These are the steps of the upgrade that I've tried with a few different React applications, but you may encounter issues I didn't encounter myself. Google is your best friend in these cases, and it will often lead you to Stackoverflow, GitHub issues, other tutorials, and maybe even source code. Don't be afraid; you'll be able to figure it out!

Note: In this tutorial, I'll refer to Create React App as CRA. React Scripts is the name of the installed package that abstracts all the configuration created by the Create React App command, and in most cases you'll see online resources use both interchangeably.

Table Of Contents

1. Prerequisites
2. How to Validate Every Step
3. How to Bump to React Scripts v4.0.3
4. How to Bump Node Version to 18
   – Understanding the MD4 Issue
5. How to Eject Out of React Scripts
   – How to Add Linter Ignores For Ejected Files
   – How to update your Dockerfile and Other Build Processes with the ejected folders
   – How to Fix Absolute Paths for Jest
   – How to update your Dockerfile and Other Build Processes with the ejected folders
6. How to Override Webpack MD4 to SHA256
7. How to Upgrade to the Latest Version of Jest
   – How to Bump to Jest 28
   – How to explicitly set jsdom as the test environment
   – How to Fix Transformer Return Type for process() and processAsync()
   – How to Bump Jest to 29
8. How Far Should I Upgrade NodeJS?
9. Should You Still Use Create React Scripts? What Alternatives Are There?
10. Conclusion
11. Alternatively: How to Upgrade to React Scripts 5.0.1

Prerequisites

To follow along with this guide, you should have a React application that is:

• created with create-react-app v4 or upgraded to use react-scripts v4. I've tested this tutorial on both scenarios.
• running on Node 16

If you're running NodeJS behind 16, I highly suggest upgrading to version 16. The upgrade path to 16 isn't too bad, but the jump from 16 to 18 creates breaking issues with CRA 4 defaults.

Our application also ran jest (v26), the most common test framework in React and shipped by default in CRA v4. If you aren't running Jest, then you can skip the steps relevant to it.

We were also using yarn, but the process should be identical with different syntax if you use any other runner/package manager like npm.

Ideally, you have some test case coverage to ensure things don't break between versions, so it's well worth taking some time to write some broad integration and unit tests before any upgrade.

I recommend using version control like git for each stage while working on a branch. I started over three different times using different upgrade strategies until I had something that worked. Here's a quick intro to git branches if you're unfamiliar with them.

I also recommend using nvm (Node Version Manager) to to swap versions quickly. You don't have to use it, and there are many other alternatives out there to manage versions, but it makes quickly switching very easy with just nvm use. I'll use nvm syntax in this tutorial, but it should be pretty similar for your tool.

How to Validate Every Step

Throughout the tutorial, to ensure things still work, you'll run the following:

• $ yarn build – End-to-end build to catch a lot of library-level issues
• $ yarn test – Regression tests to catch breaks in functionality
• $ yarn start – The starter scripts to catch many initialization bugs.

If you have any more validation steps (CI builds, Docker, staging environments, smoke tests), make sure they're working already and use them throughout the process to validate the upgrade worked correctly. For the rest of the tutorial, I'll refer to these as validation commands.

Before you start the upgrade, make sure all validation steps are working on your current Node 16 and CRA 4. At the end of the tutorial, all these validation steps should be working too. Ultimately, make sure to actually use your React application extensively as the final test once all the upgrade process is done.

Occasionally, you may need to $ rm -rf node_modules and $ rm package.lock.json / $ rm yarn.lock because some library changes may not propagate correctly. Ideally you won't need to do this, but it's reasonably safe since it just downloads all packages again.

How to Bump to React Scripts v4.0.3

Depending on when you started your project from CRA, you'll likely be at different versions along v4. First, we upgrade to the latest minor version to smooth over the rest of the upgrade process.

There shouldn't be any major breaking changes between the minor versions, but make sure to upgrade it incrementally in your package.json going from 4.0.0 -> 4.0.1 -> 4.0.2 -> 4.0.3. Going to 4.0.3 will streamline your upgrade process since these minor updates have a lot of useful bug, library, and dependency fixes while not creating new work for now.

I ran $ yarn install after each step and then checked my validation commands to ensure everything was still working.

... 
"dependencies": { 
    "react-scripts": "4.0.1", 
    ... 
}, 
...

In my projects, I didn't encounter any issues, but your mileage may vary. The official CRA v4 changelog documentation has a list of small changes and upgrade steps between the versions, which will narrow down the causes.

How to Bump Node Version to 18

After making sure your validation commands are working on your current Node 16, set your version to 18. Then we work on fixing all the validation commands until all of them work. Occasionally you may switch back to 16 to make sure things still work in the older version.

In your command line, run the following:

$ nvm install 18
$ nvm use 18

Note: If you have a .nvmrc file, you can skip the version numbers in the nvm install and nvm use commands. Update the file as you change node versions.

Unfortunately, if you try $ yarn start or $ yarn build, you'll immediately run into the cryptography error that comes from openssl, which blocks all encryption using MD4. This is the main error blocking the upgrade to Node 18 while on CRA 4.

Error: error:0308010C:digital envelope routines::unsupported

Understanding the MD4 Issue

MD4 is an old encryption algorithm from the 1990s and has been considered very insecure since 1995 (Wikipedia). OpenSSL from version 3 onward changed MD4 to not be supported by default, but it can be enabled with an allow unsafe legacy flag on your system openssl or --openssl-legacy-provider if adding it to your node/CRA script (see the Node docs).

It's a seemingly simple fix to the solution, but this is more of a last resort since allowing unsafe cryptography is generally a bad idea, and OpenSSL has disabled the algorithm entirely for a reason.

Note: If you're curious, Webpack has a 1000+ response discussion on this topic that might have something useful. Later versions of Webpack also eventually allowed a better algorithm called xxHash, added a built-in MD4 wasm implementation, and added a new config option called deterministic that sidesteps the issue.

I highly recommend reading this StackOverflow answer for a quick overview of the major options if we aren't patching it ourselves. Since upgrading dependencies isn't possible here, and we don't want to stay on an old Node version or allow insecure algorithms, we need to dive into the internals of CRA to fix it.

How to Eject Out of React Scripts

CRA is designed for a zero-configuration experience for React Apps that lets you focus on just working on your business logic.

When you want to start changing configuration, CRA doesn't have a built-in method to override any option. Instead, it offers a command called eject that copies over all the internals of CRA to your project while leaving your yarn/npm commands intact and then removing React scripts from your project entirely. It's a one-way action, so make sure you save the previous version in git.

$ yarn eject

This is a huge command that will change lots of files in the config/ and scripts/ directories as well as your list of packages in package.json. Once you rerun yarn install, make sure to run all your validation commands to make sure everything still works on Node 16 since nothing should have changed in terms of functionality.

Alternatively, if you don't want to try eject, there are also workarounds like:

• CRACO uses a clever override mechanism to allow you to still use React Scripts while customizing. Read Getting Started and Why I built CRACO. Start off with version 6.4.5 for CRA v4.
• patch-package applies specific npm package changes for your project and then you share the patch with your team/project. For this guide, you will patch react-scripts with the modified webpack and config setups.
• Forking CRA with your own modifications. This way you can still keep the zero config CRA with no hacks to patch in new functionality, but this might get complicated. Here's a guide I saw online: Customizing create-react-app: How to Make Your Own Template.

There's also react-app-rewired for a similar purpose, but it's mostly unmaintained right now and intended for older versions of CRA behind v4.

How to Add Linter Ignores for Ejected Files

A lot of the new files from the ejected configuration might not follow your existing project's linter rules. Until you're done with the upgrade, I recommend just adding new ignores on the top of the failing files like:

/* eslint-disable import/order */

// rest of file
...

Once you're done with the entire tutorial, feel free to go back and try fixing some of the linter issues, but it might be okay to leave these files as-is since you'll rarely go in to change anything.

How to Fix Absolute Paths for Jest

In your package.json, the jest "testRunner" option might be encoded to the absolute path that only makes sense on your computer. So, you'll want to change it to a path based on your project's root directory.

While this might work fine for your local development, it will break for any collaborators or cloud computers.

... 
"jest": { 
    ... 
    "testRunner": "/my/computer/path/project_name/node_modules/jest-circus/runner.js", 
    ... 
}, 
...

We use the option <rootDir> that is provided by Jest:

... 
"jest": { 
    ... 
    "testRunner": "<rootDir>/node_modules/jest-circus/runner.js", 
    ... 
}, 
...

You might not have to do this on all projects, but "modulePaths" may need an update as well:

...
"jest": { 
    ... 
    "modulePaths": [ "/my/computer/path/project_name/src" ] 
    ... 
}, 
...

Just remove the reference to your computer's absolute path:

...
"jest": { 
    ... 
    "modulePaths": [ "src" ] 
    ... 
}, 
...

How to Update your Dockerfile and Other Build Processes with the Ejected Folders

Make sure to include the new ejected folders, scripts/ and config/, into your Dockerfile and other build processes you might be using that existed outside CRA.

For example, the Dockerfile will have the additions of new directories that CRA created that we also want to copy over.

... 
COPY scripts scripts/
COPY config config/ 
...

How to Override Webpack MD4 to SHA256

Based on this StackOverflow answer, we add to webpack.config.js right before we start defining module.exports to use the relatively more modern and secure SHA256 instead of MD4 that's also built into Webpack:

// ... 
// https://stackoverflow.com/a/78005686 
const crypto = require("crypto"); 
const crypto_orig_createHash = crypto.createHash; crypto.createHash = algorithm => crypto_orig_createHash(algorithm == "md4" ? "sha256" : algorithm); 
// This is the production and development configuration. 
// It is focused on developer experience, fast rebuilds, and a minimal bundle. 
module.exports = function (webpackEnv) 
// ...

Once you've changed this, the envelope errors should disappear and your validation commands should now work for Node 18.

How to Upgrade to the Latest Version of Jest

The eject also exposes the Babel configuration used for making more recent versions of Jest work correctly. This works great for version 26 but moving the CRA config to the latest version (v29 at the time of writing) has a few more steps.

You should go through v26 -> v28 -> v29 (skipping v27) for all the Jest dependencies. This part is optional if you're happy with CRA v4's Jest 26, but until you eject, you're blocked from upgrading to a recent version of Jest.

I'm skipping Jest 27 because it'll require a change in config/jest/babelTransform.js where you'll have to change module.exports = babelJest.default.createTransformer({ to module.exports = babelJest.createTransformer({. This was a bug fixed in version 28. Still, if you want to go through Jest 27 as well, you'll be able to follow the rest of the steps with this change and then optionally reverting it on Jest 28.

I also highly recommend reading the introduction articles for each of the Jest version upgrades:

• Jest 27: New Defaults for Jest, 2021 edition ⏩
• Jest 28: Shedding weight and improving compatibility 🫶
• Jest 29: Snapshot format changes

Most of the issues come from Jest 28 having many breaking changes, but the rest of the upgrade path is fairly straightforward.

How to Bump to Jest 28

For each upgrade, I recommend doing a find and replace for all the many Jest-related packages in your package.json since the version numbers are all synced. Once you update the numbers, just run $ yarn install:

... 
"devDependencies": { 
    ...
    "babel-jest": "^28.1.3", 
    ...
    "jest": "^28.1.3", 
    "jest-circus": "^28.1.3", 
    "jest-resolve": "^28.1.3", 
    ...
} 
...

How to Explicitly Set jsdom as the Test Environment

If you try running your tests out of the box with $ yarn test. It'll give you this error:

● Validation Error: 
Test environment jest-environment-jsdom cannot be found. 
Make sure the testEnvironment configuration option points to an existing node module. 
Configuration Documentation: https://jestjs.io/docs/configuration 
As of Jest 28 "jest-environment-jsdom" is no longer shipped by default, make sure to install it separately.

In Jest 27, Jest changed the default test environment to be meant for a more lightweight NodeJS backend environment. However, we have a frontend application, so we still want to test with a simulated browser environment that older Jest versions were based off called jsdom.

To fix this, add "jest-environment-jsdom" to your dependencies and then run $ yarn install.

... 
"devDependencies": { 
    ...
    "babel-jest": "^28.1.3", 
    ...
    "jest": "^28.1.3", 
    "jest-circus": "^28.1.3", 
    "jest-resolve": "^28.1.3", 
    "jest-environment-jsdom": "^28.1.3", 
    ...
} 
...

How to Fix Transformer Return Type for process() and processAsync()

‌‌Now, if you run yarn test, you'll get this:

FAIL  src/App.test.js 
● Test suite failed to run 
● Invalid return value: `process()` or/and `processAsync()` method of code transformer found at "path/in/my/computer" 
should return an object or a Promise resolving to an object. The object must have `code` property with a string of processed code. 
This error may be caused by a breaking change in Jest 28: https://jestjs.io/docs/upgrading-to-jest28#transformer Code Transformation Documentation: https://jestjs.io/docs/code-transformation

This is because the process() functions that used to return a string now expect an object in the format of { code:old_string_here}.

To fix this, we go into our ejected config/jest folder, and we change the output shape for all our files. For CSS, it's a single line change:

// This is a custom Jest transformer turning style imports into empty objects. 
// http://facebook.github.io/jest/docs/en/webpack.html 

module.exports = { 
    process() { 
        return { code: 'module.exports = {};' }; 
    }, 
    getCacheKey() { 
        // The output is always the same. 
        return 'cssTransform'; 
    }, 
};

and for files, you have to change both branch return statements:

const path = require('path'); 
const camelcase = require('camelcase'); 

// This is a custom Jest transformer turning file imports into filenames. // http://facebook.github.io/jest/docs/en/webpack.html 
module.exports = { 
    process(src, filename) { 
        const assetFilename = JSON.stringify(path.basename(filename)); 
        if (filename.match(/\.svg$/)) { 
            // Based on how SVGR generates a component name: 
            // https://github.com/smooth-code/svgr/blob/01b194cf967347d43d4cbe6b434404731b87cf27/packages/core/src/state.js#L6 
            const pascalCaseFilename = camelcase(path.parse(filename).name, { pascalCase: true, }); 
            const componentName = `Svg${pascalCaseFilename}`; 
            return { code: `const React = require('react')...` // pretty long string }; 
        }

        return {code: `module.exports = ${assetFilename};` }; 
    }, 
};

Note: As of the time of writing, the error message link to the upgrade guide tutorial doesn't work, but you can find the correct link at https://jest-archive-august-2023.netlify.app/docs/28.x/upgrading-to-jest28/. There's also an older archive link if that doesn't work.

How to Bump Jest to 29

Once all the validation steps are working with Jest 28, the upgrade to 29 should be smoother. Just update your package.json and run $ yarn install:

... 
"devDependencies": { ... 
    "babel-jest": "^29.7.0", 
    "jest": "^29.7.0", 
    "jest-circus": "^29.7.0", 
    "jest-resolve": "^29.7.0", 
    "jest-environment-jsdom": "^29.7.0" ... 
} 
...

At this point, $ yarn test should work correctly with your existing test suite.

How Far Should I Upgrade NodeJS?

Trying to decide how far ahead to upgrade Node versions can be a tricky question. Following the above steps, I was able to get all the Node versions up until the most recent Node 22 working.

At the time of writing, 18 is a pretty good stopping point in terms of current support and recent ECMAScript support. But if you're looking to decide, then the following three factors are the most important:

1. Library support: Look at all your critical libraries and see if they have a strong preference for a certain version or have breaking issues for more recent versions. Later Node versions are usually better, but sometimes old libraries didn't get the right patches and might block your upgrade.
2. Support windows: Different Node versions have a window where the maintainers consider it under "Maintenance", "Active", "Current" or "Unsupported", and over time the older versions lose maintenance. The even versions are also designated LTS (Long Term Support), giving support for a long time and what works for most people. The website has a helpful chart for this: https://nodejs.org/en/about/previous-releases.
3. Language feature support: ECMAScript's specification is always evolving with every year, and getting to use the newer syntax with nicer constructs is always a big quality of life upgrade. I love https://node.green/ which has a table of Node versions against ECMAScript syntax features with code examples for each feature.

Due to technologies like Babel (bundled with Create React App), you don't need to worry too much about the end users of your website, as newer Node features will just get transpiled to browser-compliant ones.

Should You Still Use Create React Scripts? What Alternatives Are There?

In this tutorial, I decided to eject out of CRA to access the Webpack and Babel configuration, and many CRA projects have eventually come to do this as well. Maintenance of CRA has nearly stopped while the ecosystem keeps evolving.

Personally, I recommend someone creating a React project today to try newer alternatives like Vite or Parcel which have a nice starter applications that are simple and easier to understand. Unfortunately, they might not have as many bells and whistles as what CRA gives, but it's good enough for almost all practical modern development.

In the context of education, my old tutorials used create-react-app, and it was such a major help, but my newer ones will use Vite.

Still, your application and development experience might be very different than mine. I recommend reading and learning from these resources to form your own perspective:

• GitHub issue with 200+ responses and 1000s of reactions on if Create React App should be replaced with Vite on the official docs. It also has a note from the maintainer side of CRA explaining a lot of important context that is highly worth reading. Parcel's maintainer made a really good comment as well.
• Some interesting comments (one, two) on how CRA created a simple and easy to use React experience out of the box without worrying about setup hell and focusing on the actual application.
• News article explaining that the React Team has chosen to stop recommending Create React App, along with some context behind this and future alternatives.

Conclusion

At this point, you should be able to run all your validation scripts and have an application that works with Node 18+ and Jest 29+.

In an ideal world, you'd run into the same hurdles as I did, and everything would be working. Realistically, everyone's application is different, and the internet is full of numerous developers who have gone through this upgrade process with various issues.

I highly suggest making Google, StackOverflow, GitHub, and official library documentation your best friends in the process, and I wish you good luck!

Alternatively: How to Upgrade to React Scripts 5.0.1

This is beyond the scope of this tutorial, so I'll be briefer here – but here's a little information to get you started.

I suggest starting with the official docs changelog for CRA v5 that includes all the major changes as well as some version upgrade instructions: https://github.com/facebook/create-react-app/blob/main/CHANGELOG.md.

Bumping the version is fairly easy, setting react-scripts to 5.0.1 in your package.json, but then the hard part is all the breaking changes.

The most complicated part of the upgrade is the upgrade to Webpack 5 from Webpack 4. Read Webpack's official guide To v5 from v4 which has a nice overview, and look around the internet for guides for this upgrade. A few more hurdles that you might come across:

• For @babel/helper-compilation-targets: 'opera_mobile' is not a valid target you can add "not op_mob >= 1" to the browserslist array as suggested by this comment on the babel issue tracker. The other comments may also be helpful.
• You'll probably have to access the CRA internals for many steps using either React Scripts eject or something like CRACO version 7.
• Webpack 5 has a breaking change which removes support for a lot of browser specific APIs like os, http, util that worked in Webpack 4 that your application may have been using. You can either add all of them back using a package like node-polyfill-webpack-plugin or add imports piecewise following this cheatsheet.
• For Babel eslint parser load errors like Error: Failed to load parser 'babel-eslint' declared in '.eslintrc': Cannot find module 'babel-eslint' , you might have to swap out "parser": "babel-eslint" with "parser": "@babel/eslint-parser" in your .eslintrc and install "@babel/eslint-parser" in your package.json. This might be caused by the move of babel-eslint to the @babel monorepo, see The State of babel-eslint for more info.
• Some filetype imports that used to work with Webpack 4 will start breaking with Module build failed: UnhandledSchemeError (the actual error took several screens in my Terminal). The solution here will be fixing the prefixes of the files you import, and for external files that were being included, see if you can find a npm package for it. For example, one of my projects stopped using semantic-ui.min.css downloaded from the internet, and instead I added "semantic-ui-css": "^2.5.0" to my package.json. Definitely read this issue thread in the webpack repo for more information.

After all of these I was able to get yarn test and yarn build to succeed, but yarn start still had too many issues and I pivoted to making CRA v4 work instead. Hopefully you might get further than I did.

Testing is a vital part of software development. The sooner you start testing, the better.

In this article, I'll show you how to write tests for your NodeJs/ExpressJS and MongoDB/Mongoose applications with Jest and Supertest.

Let's get started

First let's set up a demo Express.js app.

Let's say we are building a backend REST API for an eCommerce application.

This app should:

• Get all the products
• Get a product by id
• Add product(s) to the database
• Delete product(s) from the database
• Update product information

Express.js App Set Up

Step 1: Project set up

First, create a folder and start a blank application with npm.

npm init

Fill all the details it asks for.

Then, install express, mongoose, axios and dotenv with the following command:

npm i express mongoose axios dotenv

Here's a link to the package.json on my GitHub.

Step 2: Create the boilerplate

Let's create all the folders and files and then fill them with some boilerplate code.

This is how your folder hierarchy should look:

.
├── controllers
│   └── product.controller.js
├── models
│   └── product.model.js
├── routes
│   └── product.route.js
├── package-lock.json
├── package.json
├── .env
├── app.js
└── server.js

Use these files' code by copying and pasting. Analyze the code and flow as best you can.

• [product.controller.js](https://github.com/itsrakeshhq/jest-tests-demo/blob/main/controllers/product.controller.js)
• [product.model.js](https://github.com/itsrakeshhq/jest-tests-demo/blob/main/models/product.model.js)
• [product.route.js](https://github.com/itsrakeshhq/jest-tests-demo/blob/main/routes/product.route.js)
• [app.js](https://github.com/itsrakeshhq/jest-tests-demo/blob/main/app.js)
• [server.js](https://github.com/itsrakeshhq/jest-tests-demo/blob/main/server.js)

Step 3: Database setup

I advise using two databases for a project—one for testing, the other for development. But just one database will be sufficient for learning purposes.

First, create a MongoDB account or log in.

Then create a new project. Give it a name and press the Next button.

Naming the project

Then click Create Project after that.

We must create a database in the following window by selecting a cloud provider, a location, and specs. So press Build a Database to get going.

Build a database

Choose "Shared" because it is sufficient for learning purposes. And then click Create.

Choose a deployment option

Next, select "aws" as your cloud provider and the region that is closest to you. Following your selection, click Create Cluster.

The cluster's formation will take some time. Create a user to access your database in the meanwhile.

Create Superuser

Choose "My Local Environment" because we are developing our application. You can then add an IP addresses. To conclude, click Close.

Add IP addresses

You will receive a URI string after the database is set up, which we'll use to connect to the database. The string appears as follows:

mongodb+srv://<YOUR_USERNAME>:<YOUR_PASSWORD>@<YOUR_CLUSTER_URL>/<DATABASE_NAME>?retryWrites=true&w=majority

Put this string in the .env file.

MONGODB_URI=your database string

Now we're ready to start testing our app.

How to Write Tests with Jest and SuperTest

Step 1: Install packages

You need three npm packages to begin writing tests: jest, supertest, and cross-env. You can install them like this:

npm i jest supertest cross-env

• jest: Jest is a framework for testing JavaScript code. Unit testing is the main usage of it.
• supertest: Using Supertest, we can test endpoints and routes on HTTP servers.
• cross-env: You can set environmental variables inline within a command using cross-env.

Step 2: Add test script

Open your package.json file and add the test script to the scripts.

"scripts": {
    "test": "cross-env NODE_ENV=test jest --testTimeout=5000",
    "start": "node server.js",
    "dev": "nodemon server.js"
},

In this case, we're using cross-env to set environment variables, jest to execute test suites, and testTimeout is set to 5000 because certain requests might take a while to finish.

Step 3: Start writing tests

First, create a folder called tests at the application's root, and then create a file there called product.test.js. Jest searches for the folder tests at the project's root when you do npm run test. As a result, you must place your test files in the tests folder.

Next, import the supertest and mongoose packages into the test file.

const mongoose = require("mongoose");
const request = require("supertest");

Import dotenv to load environment variables, and import app.js as that is where our application starts.

const mongoose = require("mongoose");
const request = require("supertest");
const app = require("../app");

require("dotenv").config();

You'll need to connect and disconnect the database before and after each test (because we don't require the database once testing is complete).

/* Connecting to the database before each test. */
beforeEach(async () => {
  await mongoose.connect(process.env.MONGODB_URI);
});

/* Closing database connection after each test. */
afterEach(async () => {
  await mongoose.connection.close();
});

Now you can write your first unit test.

describe("GET /api/products", () => {
  it("should return all products", async () => {
    const res = await request(app).get("/api/products");
    expect(res.statusCode).toBe(200);
    expect(res.body.length).toBeGreaterThan(0);
  });
});

In the above code,

• We use describe to describe the unit test. Even though it is not required, it will be useful to identify tests in test results.
• In it, we write the actual test code. Tell what the test performs in the first argument, and then in the second argument, write a callback function that contains the test code.
• In the callback function, the request is sent to the endpoint first, and the expected and actual responses are then compared. The test passes if both answers match, else, it fails. ✨ As simple as that ✨.

You can write tests for all the endpoints in the same manner.

describe("GET /api/products/:id", () => {
  it("should return a product", async () => {
    const res = await request(app).get(
      "/api/products/6331abc9e9ececcc2d449e44"
    );
    expect(res.statusCode).toBe(200);
    expect(res.body.name).toBe("Product 1");
  });
});

describe("POST /api/products", () => {
  it("should create a product", async () => {
    const res = await request(app).post("/api/products").send({
      name: "Product 2",
      price: 1009,
      description: "Description 2",
    });
    expect(res.statusCode).toBe(201);
    expect(res.body.name).toBe("Product 2");
  });
});

describe("PUT /api/products/:id", () => {
  it("should update a product", async () => {
    const res = await request(app)
      .patch("/api/products/6331abc9e9ececcc2d449e44")
      .send({
        name: "Product 4",
        price: 104,
        description: "Description 4",
      });
    expect(res.statusCode).toBe(200);
    expect(res.body.price).toBe(104);
  });
});

describe("DELETE /api/products/:id", () => {
  it("should delete a product", async () => {
    const res = await request(app).delete(
      "/api/products/6331abc9e9ececcc2d449e44"
    );
    expect(res.statusCode).toBe(200);
  });
});

Then run npm run test to run the test suites (suite - test file).

Test results

And that's it! You now know how to test your Express/Mongoose apps with Jest and SuperTest.

Now go forth and create new tests for your apps. :)

If you have any questions, feel free to message me on Twitter.

Consumer driven contract testing is a great way to improve the reliability of interconnected systems. Integration testing becomes way easier and more self contained. It opens the door for independent deployments, and leads to faster iterations and more granular feedback. Unlike your insurance, it doesn't have any fine print. This article is about setting it up in a delivery pipeline, in the context of doing continuous delivery.

I want to show how Contract Tests help split the deployment of the front end and the back end of a small application. I have a React client and a Spring Boot backend written in Kotlin.

What is a Contract Test?

I am not talking about smart contracts. There is no blockchain whatsoever in this article. Sorry for that (Contract Tests for Smart Contracts sounds like a conference talk that the world badly needs, though!).

In a nutshell, a Contract Test is a specification of the interactions between a consumer and a provider. In our case, the communication happens using REST. The consumer defines the actions sent to the provider and the responses that will be returned. In our case, the frontend is the consumer and the backend is the provider. A contract is generated. Both sides test against this contract.

It is not really about any particular technology. There are a bunch of different frameworks, but some simple scripts could do the trick.

Why have it as part of the delivery pipeline?

First of all, running these tests continuously ensures that they keep working at all times. The big benefit, however, is that we can separate the deployment of the front end and back end. If both sides are fulfilling the contract, it is likely that they work together correctly. Thus, we can consider avoiding expensive integrated tests. They tend to work pretty badly anyways.

Setting up some contracts

There are two sides to set up, consumer and provider. The tests will run in the pipelines that build the front end and the back end, respectively. We are going to use the Pact framework for our examples, which is the tool that I am most familiar with. Because of that, I tend to use pact and contract interchangeably. Our pipelines are written for CircleCI, but they should be fairly easy to port to other CI Tools.

The consumer side

As mentioned, the consumer leads the creation of the contract. Having the client driving this might sound counterintuitive. Often, APIs are created before the clients that will use them. Flipping it around is a nice habit to get into. It forces you to really think in terms of what the client will actually do, instead of bikeshedding a super generic API that will never need most of its features. You should give it a try!

The pact is defined through interactions specified in unit tests. We specify what we expect to be sent to the back end, and then use the client code to trigger requests. Why? We can compare expectations against actual requests, and fail the tests if they don't match.

Let's have a look at an example. We are using Jest to run the tests. We'll start with some initialization code:

import path from 'path'
import Pact from 'pact'

const provider = () =>
  Pact({
    port: 8990,
    log: path.resolve(process.cwd(), 'logs', 'pact.log'),
    dir: path.resolve(process.cwd(), 'pacts'),
    spec: 2,
    consumer: 'frontend',
    provider: 'backend'
  })

export default provider

Then we have the code for an actual test. The test consists of two parts. First we define the expected interaction. This is not very different from mocking an http library, with something like axios. It specifies the request that we will send (URL, headers, body and so forth), and the response that we will get.

const interaction: InteractionObject = {
  state: 'i have a list of recipes',
  uponReceiving: 'a request to get recipes',
  withRequest: {
    method: 'GET',
    path: '/rest/recipes',
    headers: {
      Accept: 'application/json',
      'X-Requested-With': 'XMLHttpRequest'
    }
  },
  willRespondWith: {
    status: 200,
    headers: { 'Content-Type': 'application/json; charset=utf-8' },
    body: [
      {
        id: 1,
        name: 'pasta carbonara',
        servings: 4,
        duration: 35
      }
    ]
  }
}

Then we have the test itself, where we call the actual client code that will trigger the request. I like to encapsulate these requests in services that convert the raw response into the domain model that will be used by the rest of the app. Through some assertions, we make sure that the data that we are delivering from the service is exactly what we expect.

it('works', async () => {
  const response = await recipeList()

  expect(response.data.length).toBeGreaterThan(0)
  expect(response.data[0]).toEqual({
    id: 1,
    name: 'pasta carbonara',
    servings: 4,
    duration: 35
  })
})

Note that even if recipeList is properly typed with TypeScript, that won't help us here. Types disappear at runtime, so if the method is returning an invalid Recipe we won't realize it, unless we explicitly test for it.

Finally we need to define some extra methods that will ensure that the interactions are verified. If there are interactions missing, or they don't look like they should, the test will fail here. After that, all that remains is writing the pact to disk.

beforeAll(() => provider.setup())
afterEach(() => provider.verify())
afterAll(() => provider.finalize())

In the end, the pact gets generated as a JSON file, reflecting all the interactions that we have defined throughout all our tests.

Flexible matching

Our pact thus far is specifying the exact values that it will get from the backend. That won't be maintainable in the long run. Certain things are inherently harder to pin down to exact values (for example, dates).

A pact that breaks constantly will lead to frustration. We are going through this whole process to make our life easier, not harder. We'll avoid that by using matchers. We can be more flexible and define how things will look like, without having to provide exact values. Let's rewrite our previous body:

willRespondWith: {
  status: 200,
  headers: { 'Content-Type': 'application/json; charset=utf-8' },
  body: Matchers.eachLike({
    id: Matchers.somethingLike(1),
    name: Matchers.somethingLike('pasta carbonara'),
    servings: Matchers.somethingLike(4),
    duration: Matchers.somethingLike(35)
  })
}

You can be more specific. You can set the expected length of a list, use regexes and a bunch of other things.

Integrating it in the pipeline

The pact tests rely on an external process, and having multiple tests hitting it can lead to non deterministic behavior. One solution is to run all the tests sequentially:

npm test --coverage --runInBand

If you want to run the pact tests independently, we can build our own task to run them separately:

"scripts": {
  "pact": "jest --transform '{\"^.+\\\\.ts$\": \"ts-jest\"}' --testRegex '.test.pact.ts$' --runInBand"
}

Which will become an extra step in our pipeline:

jobs:
  check:
    working_directory: ~/app

    docker:
      - image: circleci/node:12.4

    steps:
      - checkout
      - run: npm
      - run: npm run linter:js
      - run: npm test --coverage --runInBand
      - run: npm pact

Storing the pact

Our pact is a json file that we are going to commit directly in the frontend repository, after running the tests locally. I've found that this tends to work well enough. Making the pipeline itself commit the pact to git does not seem to be necessary.
We'll get to extending the pact and in a second.

The provider side

At this point we have a working pact, that is being verified by the consumer. But that is only half of the equation. Without a verification from the provider side, we haven't accomplished anything. Maybe even less than that, because we might get a false sense of security!

To do this, we are going to start the back end as a development server and run the pact against it. There is a gradle provider that takes care of this. We need to configure it and provide a way of finding the pact (which is stored in the front end repository). You can fetch the pact from the internet, or from a local file, whichever is more convenient.

buildscript {
    dependencies {
        classpath 'au.com.dius:pact-jvm-provider-gradle_2.12:3.6.14'
    }
}

apply plugin: 'au.com.dius.pact'

pact {
    serviceProviders {
        api {
            port = 4003

            hasPactWith('frontend') {
                pactSource = url('https://path-to-the-pact/frontend-backend.json')
                stateChangeUrl = url("http://localhost:$port/pact")
            }
        }
    }
}

What remains is starting the server and running the pact against it, which we do with a small script:

goal_test-pact() {
  trap "stop_server" EXIT

  goal_build
  start_server

  ./gradlew pactVerify
}

start_server() {
  artifact=app.jar
  port=4003

  if lsof -i -P -n | grep LISTEN | grep :$port > /dev/null ; then
    echo "Port[${port}] is busy. Server won't be able to start"
    exit 1
  fi

  nohup java -Dspring.profiles.active=pact -jar ./build/libs/${artifact} >/dev/null 2>&1 &

  # Wait for server to answer requests
  until curl --output /dev/null --silent --fail http://localhost:$port/actuator/health; do
    printf '.'
    sleep 3
  done
}

stop_server() {
  pkill -f 'java -Dspring.profiles.active=pact -jar'
}

Fixtures

If you are running your back end in development mode, it will have to deliver some data, so that the contract is fulfilled. Even if we are not using exact matching, we have to return something, otherwise it won't be possible to verify it.

You can use mocks, but I've found that avoiding them as much as possible leads to more trustworthy results. Your app is closer to what will happen in production. So what other options are there? Remember that when we were defining interactions, we had a state. That's the cue for the provider. One way of using it is the stateChangeUrl. We can provide a special controller to initialize our back end based on the state:

private const val PATH = "/pact"

data class Pact(val state: String)

@RestController
@RequestMapping(PATH, consumes = [MediaType.APPLICATION_JSON_VALUE])
@ConditionalOnExpression("\${pact.enabled:true}")
class PactController(val repository: RecipeRepository) {
    @PostMapping
    fun setup(@RequestBody body: Pact): ResponseEntity<Map<String,String>> {
        when(body.state) {
            "i have a list of recipes" -> initialRecipes()
            else -> doNothing()
        }

        return ResponseEntity.ok(mapOf())
    }
}

Note that this controller is only active for a specific profile, and won't exist outside of it.

Integrating it in the pipeline

As with the provider, we will run the check as part of our pipeline

version: 2
jobs:
  build:

    working_directory: ~/app

    docker:
      - image: circleci/openjdk:8-jdk

    steps:

      - checkout
      - run: ./go linter-kt
      - run: ./go test-unit
      - run: ./go test-pact

There is a slight difference, though. Our contract gets generated by the consumer. That means that a change in the front end could lead to a pact that does not verify properly anymore, even though no code was changed in the back end. So ideally, a change in the pact should trigger the back end pipeline as well. I haven't found a way to represent this elegantly in CircleCI, unlike say ConcourseCI.

How the contract influences the relationship between front end and back end

It's nice that we got this set up. Never touch a running system, right? Well, we might! After all, quick change is why we invest in all this tooling. How would you introduce a change that requires extending the API?

1. We start with the client. We want to define what the client will get that is not there yet. As we learned, we do that through a test in the front end that defines the expectation for the new route, or the new fields. That will create a new version of the pact.
2. Note that at this point the back end does not fulfill the pact. A new deployment of the back end will fail. But also, the existing backend does not fulfill the pact either right now. The change you introduced has to be backwards compatible. The front end should not be relying on the changes, either.
3. Now it's time to fulfill the new pact from the back end side. If this takes a long time, you will block your deployment process, which is not good. Consider doing smaller increments in that case. Anyways, you've got to implement the new functionality. The pact test will verify that your change is what's actually expected.
4. Now that the back end is providing the new functionality, you can freely integrate it in your front end.

This flow can get a bit awkward in the beginning. It is really important to work with the smallest quantum of functionality. You don't want to block your deployment process.

Next steps

For the integration between your own front end and back end I have found this setup to be sufficient in practice. However, as complexity grows, versioning will become important. You'll want to help multiple teams collaborate more easily. For that, we can use a broker. This is a lot harder to implement, so you should ask yourself if you really need it. Don't fix problems that you don't have yet.

Conclusion

To summarize, this is the setup we arrived at:

Think about all the time you have spent writing tests to check that your back end is sending the right data. That is a lot more convenient to do with a contract. Moreover, releasing front end and back end independently means being faster, releasing smaller pieces of functionality. It might feel scary at first, but you will realize that you actually are much more aware of what's going out that way.

Once you have adopted this for one service, there is no reason not to do it for all of them. I really don't miss running costly end to end test suites just to verify that my back end is working. Here is the code that I used in the examples for the front end and the back end. It is a full running (albeit small) application. Good luck with your contracts!

When I first started learning to test my apps back in the day, I would get very frustrated with the different types, styles and technologies used for testing, along with the disbanded array of blog posts, tutorials and articles. I found this to be true as well for React testing.

So I decided to just write a complete React testing guide in one article.

Complete Guide, huh, are you going to cover every possible testing scenario? Of course not. However, it will be a complete foundational guide to testing and will be enough to build off of for most other edge cases.

Also I have curated an extensive collection of blog posts, articles and tutorials in the further reading section at the end that should give you enough knowledge to be in the top 10% of developers in terms of testing.

You can find the completed project here:

https://github.com/iqbal125/react-hooks-testing-complete

Table of Contents

Theory

• What is Testing?
• Why Test?
• What to Test?
• What Not to Test?
• How I test
• Shallow vs Mount

• unit vs integration vs e to e

  Preliminary Info

• a few odds and ends

  Enzyme

• Enyme Setup

• react-test-renderer
• snapshot testing

• testing implementation details

  React Testing Library

• useState and props

• useReducer()
• useContext()
• Controlled component Forms

• useEffect() and Axios API requests

  Cypress

• A complete end to end test

  Continuous Integration

• Travis.yml

• Code Coverage with coveralls

Theory

What is testing?

Let's start at the beginning and discuss what testing is. Testing is a 3 step process that looks like this:

Arrange, your app is in a certain original state. Act, then something happens (click event, input, etc.). Then you assert, or make a hypothesis, of the new state of your app. The tests will pass if your hypothesis is correct and fail if it is wrong.

Unlike your react components, your tests are not executed in the browser. Jest is the test runner and testing framework used by React. Jest is the environment where all your tests are actually executed. This is why you do not need to import expect and describe into this file. These functions are already available globally in the jest environment.

Your tests syntax will look something like this:

describe('Testing sum', () => {
    function sum(a, b) {
       return a + b;
    }

    it('should equal 4',()=>{
       expect(sum(2,2)).toBe(4);
      })

    test('also should equal 4', () => {
        expect(sum(2,2)).toBe(4);
      }) 
});

describe wraps our it or test blocks, and is a way to group our tests. Both it and test are keywords and can be used interchangeably. The string will be something that should happen with your tests and will be printed to the console. toBe() is a matcher that works with expect to allow you to make assertions. There are many more matchers and global variables offered by jest, see the links below for a complete list.

https://jestjs.io/docs/en/using-matchers

https://jestjs.io/docs/en/api

Why test?

Testing is done to ensure that your app will work as intended for your end users. Having tests will make your app more robust and less error prone. It is a way to verify that the code is doing what the developers intended.

Potential Drawbacks:

• Writing tests is time consuming and difficult.
• In certain scenarios executing tests in CI can cost actual money.
• If done incorrectly, it can give you false positives. Your tests pass, but your app doesn’t function as intended.
• Or false negatives. Your tests fail but your app is functioning as intended.

What to test?

To build upon the previous point, Your tests should test the functionality of the app, that mimic how it will be used by your end users. This will give you confidence that your app will function as intended in your production environment. We will of course go into much more detail through out this article but this is the basic gist of it.

What not to test?

I like to use Kent C dodds philosophy here that you shouldn’t test implementation details.

Implementation details meaning testing things that are not end user functionality. We will see an example of this in the Enzyme section below.

It seems that you are testing functionality there but you are actually not. You are testing the name of the function. Because you can change the name of the function and your tests will break but your app will still work giving you a false negative.

Constantly having to worry about function and variable names is a headache, and having to rewrite tests every time you change them is tedious, I will show you a better approach.

Const variables: these are unchanging variables, no need to test them.

Third party libraries: It is not your job to test these libraries. It is up to the creators of these libraries to test it. If you are not sure if a library is tested you should not use it. Or you can read the source code to see if the author included tests. You can download the source code and run these tests yourself. You can also ask the author if their library is production ready or not.

My personal philosophy on testing

A lot of my testing philosophy is based on Kent C dodds teachings so you will see a lot of his sentiments echoed here, but I some of my own thoughts as well.

Many integration tests. No snapshot tests. Few unit tests. Few e to e tests.

Unit testing is step above snapshot testing but its not ideal. It is however much easier to understand and maintain then snapshot testing.

Write mostly integration tests. Unit tests are good but they don't really resemble the way your end user interacts with your app. It is very easy to test implementation details with unit tests, especially with shallow render.

Integration tests should mock as little as possible

Do not test implementation details such as names of functions and variables.

For example if we are testing a button and change the name of the function in the onClick method from increment() to handleClick() our tests would break but our component will still function. This is bad practice because we are basically just testing the name of the function which is an implementation detail, which our end user does not care about.

Shallow vs mount

Mount actually executes the html, css and js code like a browser would, but does so in a simulated way. It is “headless” for example, meaning it doesn’t render or paint anything to a UI, but acts as a simulated web browser and executes the code in the background.

Not spending time painting anything to the UI makes your tests much faster. However mount tests are still much slower than shallow tests.

This is why you unmount or cleanup the component after each test, because it’s almost a live app and one test will affect another test.

Mount/render is typically used for integration testing and shallow is used for unit testing.

shallow rendering only renders the single component we are testing. It does not render child components. This allows us to test our component in isolation.

For example consider this child and parent component.

import React from 'react';

const App = () => {
  return (
    <div> 
      <ChildComponent /> 
    </div> 
  )
}

const ChildComponent = () => {
  return (
    <div>
     <p> Child components</p>
    </div>
  )
}

If we used shallow rendering of App.js we would get something like this, notice none of the DOM nodes for the child component are present, hence the term shallow render.

<App>
  <div> 
    <ChildComponent /> 
  </div>
</App>

Now we can compare this to mounting the component:

<App>
  <div> 
    <ChildComponent> 
      <div>
       <p> Child components</p>
      </div>
    </ChildComponent>
   </div>
</App>

What we have above is much closer to what our app will look like in the browser, hence the superiority of mount/render.

unit vs integration vs end to end

unit testing: testing an isolated part of your app, usually done in combination with shallow rendering. example: a component renders with the default props.

integration testing: testing if different parts work or integrate with each other. Usually done with mounting or rendering a component. example: test if a child component can update context state in a parent.

e to e testing: Stands for end to end. Usually a multi step test combining multiple unit and integration tests into one big test. Usually very little is mocked or stubbed. Tests are done in a simulated browser, there may or may not be a UI while the test is running. example: testing an entire authentication flow.

Preliminary Info

react-testing-library: I personally like to use react-testing-library but the common way is to use Enzyme. I will show you one example of Enzyme because it is important to be aware of Enzyme at a basic level and the rest of the examples with react-testing-library.

Examples Outline: Our examples will follow a pattern. I will first show you the React component and then the tests for it, with detailed explanations of each. You can also follow along with the repo linked at the beginning.

Configuration: I will also assume you are using create-react-app with the default testing setup with jest so I will skip manual configurations.

Sinon, mocha, chai: A lot of the functionality offered by sinon is available by default with jest so you dont need sinon. Mocha and chai are a replacement for jest. Jest comes pre configured out of the box to work with your app, so it doesnt make sense to use Mocha and chai.

Components Naming scheme: My naming scheme for the components is <TestSomething /> but that does not mean they are fake components in any way. They are regular React components, this is just the naming scheme.

npm test and jest watch mode: yarn test worked for me. npm test did not work correctly with jest watch mode.

testing a single file: yarn test name of file

React Hooks vs Classes: I use React Hooks components for most of the examples but due to the power of react-testing-library all these tests will directly work with class components as well.

With the preliminary background info out of the way we can go over some code.

Enzyme

Enzyme Setup

Our third party libraries

npm install enzyme enzyme-to-json enzyme-adapter-react-16

Lets first start with our imports

import React from 'react';
import ReactDOM from 'react-dom';
import Basic from '../basic_test';

import Enzyme, { shallow, render, mount } from 'enzyme';
import toJson from 'enzyme-to-json';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() })

We will start with our basic imports Our first 3 imports are for react and our component.

After this we import Enzyme. Then we import the toJson function from the 'enzyme-to-json' library. We will need this to convert our shallow rendered component into JSON which can be saved to the snapshot file.

Finally we import our Adapter to make enzyme work with react 16 and initialize it as shown above.

react-test-renderer

React actually comes with its own test renderer you can use instead of enzyme and the syntax will look like this.

// import TestRenderer from 'react-test-renderer';
// import ShallowRenderer from 'react-test-renderer/shallow';


// Basic Test with React-test-renderer
// it('renders correctly react-test-renderer', () => {
//   const renderer = new ShallowRenderer();
//   renderer.render(<Basic />);
//   const result = renderer.getRenderOutput();
//
//   expect(result).toMatchSnapshot();
// });

But even the react-test-render docs suggest using enzyme instead because it has a slightly nicer syntax and does the same thing. Just something to be aware of.

SnapShot Testing

Now our first test which is a snapshot test

it('renders correctly enzyme', () => {
  const wrapper = shallow(<Basic />)

  expect(toJson(wrapper)).toMatchSnapshot();
});

If you have not ran this command before, a snapshots folder and test.js.snap file will be created for you automatically. On every subsequent test the new snapshot will be compared to the existing snapshot file. The test will pass if the snapshot has not changed and fail if it has changed.

So essentially snapshot testing allows you to see how your component has changed since the last test, line for line. The lines of code that have changed is known as the diff.

Here is our basic component we are snapshot testing:

import React from 'react';


const Basic = () => {
  return (
    <div >
      <h1> Basic Test</h1>
         <p> This is a basic Test Component</p>
    </div>
  );
}

export default Basic;

Running the above test will generate a file that will look like this. This is essentially our tree of React DOM nodes.

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`renders correctly enzyme 1`] = `
<div>
  <h1>
     Basic Test
  </h1>
  <p>
     This is a basic Test Component
  </p>
</div>
`;

And will produce a folder structure that will look like this:

Your terminal output will look like this:

However what happens if we changed our basic component to this

import React from 'react';


const Basic = () => {
  return (
    <div >
      <h1> Basic Test</h1>

    </div>
  );
}

export default Basic;

Our snapshots will now fail

And will also give us the diff

Just like in git the " - " before each line means it was removed.

We just need to press "w" to activate watch mode then press "u" to update the snapshot.

our snap shot file will be automatically updated with the new snapshot and will pass our tests

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`renders correctly enzyme 1`] = `
<div>
  <h1>
     Basic Test
  </h1>
</div>
`;

This is it for snapshot testing but if you read my personal thoughts section you know I dont snapshot test. I included it here because like Enzyme it is very common and something you should be aware of, but below I'll try to explain why I dont use it.

Let's go over again what snapshot testing is. It essentially allows you to see how your component has changed since the last test. What are the benefits of this.

• Its very quick and easy to implement and sometimes requires only a few lines of code.
• You can see if our component is rendering correctly. You can see the DOM nodes clearly with the .debug() function.

Cons, Arguments against snapshot testing:

• The only thing a snapshot test does is tell you whether the syntax of your code has changed since the last test.
• So what is it really testing? Some would argue not much.
• Also basic rendering of the app correctly is React’s job so you're going a little into testing a third party library territory.
• Also comparing diffs can be done with git version control. This should not be the job of snapshot testing.
• A failed test doesn’t mean your app isn’t working as intended, only that your code has changed since the last time you ran the test. This can lead to a lot of false negatives and a lack of trust in the test. This can also lead to people just updating the test without looking too closely at it.
• Snapshot testing also tells you if your JSX is syntactically correct, but again this can be easily done in the dev environment. Running a snapshot test just to check syntax errors doesnt make any sense.
• It can become hard to understand what’s happening in a Snapshot test, since most people use snapshot testing with shallow rendering, which doesnt render child components so it doesnt give the developer any insights at all.

See the further reading section for more info

Testing Implementation details with Enzyme

Here I will give an example on why not to test implementation details. Say we have simple counter component like so:

import React, { Component } from 'react';


class Counter extends Component {
  constructor(props) {
    super(props)

    this.state = {
      count: 0
    }
  }

  increment = () => {
    this.setState({count: this.state.count + 1})
  }

  //This incorrect code will still cause tests to pass
  // <button onClick={this.incremen}>
  //   Clicked: {this.state.count}
  // </button>

  render() {
    return (
      <div>
        <button className="counter-button" onClick={this.incremen}>
          Clicked: {this.state.count}
        </button>
      </div>
  )}
}

export default Counter;

You will notice I have a comment suggesting that a non-working app will still cause the tests to pass, for example by misspelling the name of the function in the onClick event.

And let's see the tests which will make it clear why.

import React from 'react';
import ReactDOM from 'react-dom';
import Counter from '../counter';

import Enzyme, { shallow, render, mount } from 'enzyme';
import toJson from 'enzyme-to-json';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() })

// incorrect function assignment in the onClick method
// will still pass the tests.

test('the increment method increments count', () => {
  const wrapper = mount(<Counter />)

  expect(wrapper.instance().state.count).toBe(0)

  // wrapper.find('button.counter-button').simulate('click')
  // wrapper.setState({count: 1})
  wrapper.instance().increment()
  expect(wrapper.instance().state.count).toBe(1)
})

Running the above code will pass the tests. So will using wrapper.setState(). So we have passing tests with a non functional app. I dont know about you but this doesnt give me confidence that our app will function as intended for our end users.

Simulating click on the button will not pass the tests but it might give us the opposite problem, a false negative. Say we want to change the styling on the button by declaring a new CSS class for it, a very common situation. Our tests will now fail because we cant find our button anymore but our app will still be working, giving us a false negative. This is also true whenever we change the names of our functions or state variables.

Every time we want to change our function and CSS class names we have to rewrite our tests, a very inefficient and tedious process.

So what can we do instead?

React-testing-library

useState

From the react-testing-library docs we see that the main guiding principle is

The more your tests resemble the way your software is used the more confidence they can give you.

We will keep this guiding principle in mind as we explore further with our tests.

Let's start with a basic React Hooks component and test the state and props.

import React, { useState } from 'react';


const TestHook = (props) => {
  const [state, setState] = useState("Initial State")

  const changeState = () => {
    setState("Initial State Changed")
  }

  const changeNameToSteve = () => {
    props.changeName()
  }

  return (
  <div>
    <button onClick={changeState}>
      State Change Button
    </button>
    <p>{state}</p>
    <button onClick={changeNameToSteve}>
       Change Name
    </button>
    <p>{props.name}</p>
  </div>
  )
}


export default TestHook;

Our props are coming from the root parent component

  const App = () => {
      const [state, setState] = useState("Some Text")
      const [name, setName] = useState("Moe")
  ...
      const changeName = () => {
        setName("Steve")
      }

      return (
        <div className="App">
         <Basic />
        <h1> Counter </h1>
         <Counter />
        <h1> Basic Hook useState </h1>
         <TestHook name={name} changeName={changeName}/>
    ...

So keeping our guiding principle in mind, what will our tests look like?

The way our end user will use this app will be to: see some text on the UI, see the text in the button, then click on it, finally see some new text on UI.

This is how we will write our tests using the React testing library.

Use this command to install react testing library.

npm install @testing-library/react

not

npm install react-testing-library

Now for our tests

import React from 'react';
import ReactDOM from 'react-dom';
import TestHook from '../test_hook.js';
import {render, fireEvent, cleanup} from '@testing-library/react';
import App from '../../../App'

afterEach(cleanup)

it('Text in state is changed when button clicked', () => {
    const { getByText } = render(<TestHook />);

    expect(getByText(/Initial/i).textContent).toBe("Initial State")

    fireEvent.click(getByText("State Change Button"))

    expect(getByText(/Initial/i).textContent).toBe("Initial State Changed")
 })


it('button click changes props', () => {
  const { getByText } = render(<App>
                                <TestHook />
                               </App>)

  expect(getByText(/Moe/i).textContent).toBe("Moe")

  fireEvent.click(getByText("Change Name"))

  expect(getByText(/Steve/i).textContent).toBe("Steve")
})

We first start with our usual imports.

Next we have the afterEach(cleanup) function. Since we are not using shallow render we have to unmount or cleanup after every test. And this is exactly what this function is doing.

getByText is the query method we get by using object destructuring on the value of the render function. There are several more query methods but this is the one you will want to use most of the time.

To test our state notice we are not using any function names or the names of our state variables. We are keeping with our guiding principle and not testing implementation details. Since a user will see the text on the UI, this is how we will query the DOM nodes. We will also query the button this way and click it. Finally we will query the final state based on the text as well.

(/Initial/i) is a regex expression that returns the first node that at least contains the text "Initial".

We can do the same exact thing with props as well. Since the props are going to be changed in App.js we will need to render it along with our component. Like the previous example we are not using function and variable names. We are testing the same way a user would use our app and that is through the text they will see.

Hopefully this gives you a good idea of how to test with the react-testing-library and the guiding principle, you generally want to use getByText most of the time. There are a few exceptions we will see as we continue further.

useReducer

Now we can test a component with the useReducer hook. We will of course need actions and reducers to work with our component so let's set them up like so:

Our reducer

import * as ACTIONS from './actions'

export const initialState = {
    stateprop1: false,
}

export const Reducer1 = (state = initialState, action) => {
  switch(action.type) {
    case "SUCCESS":
      return {
        ...state,
        stateprop1: true,
      }
    case "FAILURE":
      return {
        ...state,
        stateprop1: false,
      }
    default:
      return state
  }
}

And the actions:

export const SUCCESS = {
  type: 'SUCCESS'
}

export const FAILURE = {
  type: 'FAILURE'
}

we will keep things simple and use actions instead of action creators.

And finally the component that will use these actions and reducers:

import React, { useReducer } from 'react';
import * as ACTIONS from '../store/actions'
import * as Reducer from '../store/reducer'


const TestHookReducer = () => {
  const [reducerState, dispatch] = useReducer(Reducer.Reducer1, Reducer.initialState)

  const dispatchActionSuccess = () => {
    dispatch(ACTIONS.SUCCESS)
  }

  const dispatchActionFailure = () => {
    dispatch(ACTIONS.FAILURE)
  }


  return (
    <div>
       <div>
        {reducerState.stateprop1
           ? <p>stateprop1 is true</p>
           : <p>stateprop1 is false</p>}
       </div>
       <button onClick={dispatchActionSuccess}>
         Dispatch Success
       </button>
    </div>
  )
}


export default TestHookReducer;

This is a simple component that will change stateprop1 from false to true by dispatching a SUCCESS action.

And now for our test.

import React from 'react';
import ReactDOM from 'react-dom';
import TestHookReducer from '../test_hook_reducer.js';
import {render, fireEvent, cleanup} from '@testing-library/react';
import * as Reducer from '../../store/reducer';
import * as ACTIONS from '../../store/actions';


afterEach(cleanup)

describe('test the reducer and actions', () => {
  it('should return the initial state', () => {
    expect(Reducer.initialState).toEqual({ stateprop1: false })
  })

  it('should change stateprop1 from false to true', () => {
    expect(Reducer.Reducer1(Reducer.initialState, ACTIONS.SUCCESS ))
      .toEqual({ stateprop1: true  })
  })
})

it('Reducer changes stateprop1 from false to true', () => {
   const { container, getByText } = render(<TestHookReducer />);

   expect(getByText(/stateprop1 is/i).textContent).toBe("stateprop1 is false")

   fireEvent.click(getByText("Dispatch Success"))

   expect(getByText(/stateprop1 is/i).textContent).toBe("stateprop1 is true")
})

We first start off by testing our reducer. And we can wrap the tests for the reducer in the describe block. These are fairly basic tests we are using to make sure the initial state is what we want and the actions produce the output we want.

You can make an argument that testing the reducer is testing implementation details, but I found in practice that testing actions and reducers is one unit test that is always necessary.

This is a simple example so it doesn't seem like its a big deal but in larger more complex apps not testing reducers and actions can prove disastrous. So actions and reducers would be one exception to the testing implementation details rule.

Next we have our tests for the actual component. Notice again here we are not testing implementation details. We use the same pattern from the previous useState example we are getting our DOM nodes by the text and also finding and clicking the button with the text as well.

useContext

Let's now move on and test if a child component can update the context state in a parent component. This may seem complex but it is rather simple and straight forward.

We will first need our context object that we can initialize in its own file.

import React from 'react';

const Context = React.createContext()

export default Context

We also need our parent app component which will hold the Context provider. The value passed down to the Provider will be the state value and the setState function of the App.js component.

import React, { useState } from 'react';
import TestHookContext from './components/react-testing-lib/test_hook_context';


import Context from './components/store/context';


const App = () => {
  const [state, setState] = useState("Some Text")


  const changeText = () => {
    setState("Some Other Text")
  }


  return (
    <div className="App">
    <h1> Basic Hook useContext</h1>
     <Context.Provider value={{changeTextProp: changeText,
                               stateProp: state
                                 }} >
        <TestHookContext />
     </Context.Provider>
    </div>
  );
}

export default App;

And for our component

import React, { useContext } from 'react';

import Context from '../store/context';

const TestHookContext = () => {
  const context = useContext(Context)

  return (
    <div>
    <button onClick={context.changeTextProp}>
        Change Text
    </button>
      <p>{context.stateProp}</p>
    </div>
  )
}


export default TestHookContext;

We have a simple component that displays the text we initialized in App.js and also we pass the setState function to the onClick method.

Note: The state is changed, initialized and contained in our App.js component. We have simply passed down the state value and setState function to our child component through context, but ultimately the state is handled in the App.js component. This will be important to understanding our test.

And our test:

import React from 'react';
import ReactDOM from 'react-dom';
import TestHookContext from '../test_hook_context.js';
import {act, render, fireEvent, cleanup} from '@testing-library/react';
import App from '../../../App'

import Context from '../../store/context';

afterEach(cleanup)

it('Context value is updated by child component', () => {

   const { container, getByText } = render(<App>
                                            <Context.Provider>
                                             <TestHookContext />
                                            </Context.Provider>
                                           </App>);

   expect(getByText(/Some/i).textContent).toBe("Some Text")

   fireEvent.click(getByText("Change Text"))

   expect(getByText(/Some/i).textContent).toBe("Some Other Text")
})

Even for context you can see we don't break our pattern of tests, we still find and simulate our events with the text.

I have included the <Context.Provider/> and <TestHookContext /> components in the render function because it makes the code easier to read but we actually dont need either of them. Our test will still work if we passed only the <App /> component to the render function.

const { container, getByText } = render(<App/>)

Why is this the case?

Let's think back to what we know about context. All the context state is handled in App.js, for this reason this is the main component we are actually testing, even though it seems like we are testing the child component that uses the useContext Hook. This code also works because of mount/render. As we know in shallow render the child components are not rendered, but in mount/render they are. Since <Context.Provider /> and <TestHookContext /> are both child components of <App /> they are rendered automatically.

Controlled component Forms

A controlled component form essentially means the form will work through the React state instead of the form maintaining its own state. Meaning the onChange handler will save the input text to the React state on every keystroke.

Testing the form will be a little bit different than what we have seen so far, but we will try to still keep our guiding principle in mind.

import React, { useState } from 'react';

const HooksForm1 = () => {
  const [valueChange, setValueChange] = useState('')
  const [valueSubmit, setValueSubmit] = useState('')

  const handleChange = (event) => (
    setValueChange(event.target.value)
  );

  const handleSubmit = (event) => {
    event.preventDefault();
    setValueSubmit(event.target.text1.value)
  };

    return (
      <div>
       <h1> React Hooks Form </h1>
        <form data-testid="form" onSubmit={handleSubmit}>
          <label htmlFor="text1">Input Text:</label>
          <input id="text1" onChange={handleChange} type="text" />
          <button type="submit">Submit</button>
        </form>
        <h3>React State:</h3>
          <p>Change: {valueChange}</p>
          <p>Submit Value: {valueSubmit}</p>
        <br />
      </div>
    )
}


export default HooksForm1;

This is a basic form we have here and we also display the value of the change and submit value in our JSX. We have the data-testid="form" attribute which we will use in our test to the query for the form.

And our tests:

import React from 'react';
import ReactDOM from 'react-dom';
import HooksForm1 from '../test_hook_form.js';
import {render, fireEvent, cleanup} from '@testing-library/react';

afterEach(cleanup)

//testing a controlled component form.
it('Inputing text updates the state', () => {
    const { getByText, getByLabelText } = render(<HooksForm1 />);

    expect(getByText(/Change/i).textContent).toBe("Change: ")

    fireEvent.change(getByLabelText("Input Text:"), {target: {value: 'Text' } } )

    expect(getByText(/Change/i).textContent).not.toBe("Change: ")
 })


 it('submiting a form works correctly', () => {
     const { getByTestId, getByText } = render(<HooksForm1 />);

     expect(getByText(/Submit Value/i).textContent).toBe("Submit Value: ")

     fireEvent.submit(getByTestId("form"), {target: {text1: {value: 'Text' } } })

     expect(getByText(/Submit Value/i).textContent).not.toBe("Submit Value: ")
  })

Since an empty input element does not have text, we will use a getByLabelText() function to get the input node. This will still be keeping with our guiding principle, since the label text is what the user will read before inputting text.

Notice we will fire the .change() event instead of the usual .click() event. We also pass in dummy data in the form of:

{ target: { value: "Text" } }

Since the value from the form will be accessed in the form of event.target.value, this is what we pass to the simulated event.

Since we will generally not know what the text is the user will submit, we can just use a .not keyword to make sure the text has changed in our render method.

We can test the submitting of the form in a similar way. The only difference is we use the .submit() event and pass in dummy data in this way:

{ target: { text1: { value: 'Text' } } }

This is how to access form data from the synthetic event when a user submits a form. where text1 is the id of our input element. We will have to break our pattern a little bit here, and use the data-testid="form" attribute to query for the form since there is really no other way to get the form.

And thats it for the form. It isnt that different from our other examples. If you think you got it, let's move onto something a little more complex.

###

useEffect and API requests with axios

Let's now see how we would test the useEffect hook and API requests. This will be fairly different than what we have seen so far.

Say we have a url passed down to a child component from the root parent.

...

     <TestAxios url='https://jsonplaceholder.typicode.com/posts/1' />

 ...

And the component itself.

import React, { useState, useEffect } from 'react';
import axios from 'axios';


const TestAxios = (props) => {
  const [state, setState] = useState()

  useEffect(() => {
    axios.get(props.url)
      .then(res => setState(res.data))
  }, [])


  return (
    <div>
    <h1> Axios Test </h1>
        {state
          ? <p data-testid="title">{state.title}</p>
          : <p>...Loading</p>}
    </div>
  )
}


export default TestAxios;

We simply make an API request and save the results in the local state. We also use a ternary expression in our render method to wait until the request is complete to display the title data from json placeholder.

You will notice we will again out of necessity have to make use of the data-testid attribute, and again it is an implementation detail since a user will not see or interact with this attribute in any way, but this is more realistic, since we will generally not know the text from a API request beforehand.

We will also be using mocks in this test.

A mock is way to simulate behavior we dont actually want to do in our tests. For example we mock API requests because we dont want to make real requests in our tests.

We dont want to make real API requests in our tests for various reasons: it will make our tests much slower, might give us a false negative, the API request will cost us money, or we will mess up our database with test data.

import React from 'react';
import ReactDOM from 'react-dom';
import TestAxios from '../test_axios.js';
import {act, render, fireEvent, cleanup, waitForElement} from '@testing-library/react';

import axiosMock from "axios";

We have our usual imports but you will notice something peculiar. We are importing axiosMock from the axios library. We are not importing a mock axios object from the axios library. We are actually mocking the axios library itself.

How?

By using the mocking functionality offered by jest.

We first will make a __mocks__ folder adjacent to our test folder, so something like this.

And inside the mocks folder we have an axios.js file and this is our fake axios library. And inside our fake axios library we have our jest mock function.

Mock functions allow us to use functions in our jest environment without having to implement the actual logic of the function.

So basically we are not going to implement the actual logic behind an axios get request. We will just use this mock function instead.

export default {
  get: jest.fn(() => Promise.resolve({ data: {} }) )
};

Here we have our fake get function. It is a simple function that is actually a JS object. get is our key and the value is the mock function. Like an axios API request, we resolve a promise. We wont pass in any data here, we will do that in our testing setup.

Now our testing setup

//imports
...

afterEach(cleanup)

it('Async axios request works', async () => {
  axiosMock.get.mockResolvedValue({data: { title: 'some title' } })

  const url = 'https://jsonplaceholder.typicode.com/posts/1'
  const { getByText, getByTestId, rerender } = render(<TestAxios url={url} />);

  expect(getByText(/...Loading/i).textContent).toBe("...Loading")

  const resolvedEl = await waitForElement(() => getByTestId("title"));

  expect((resolvedEl).textContent).toBe("some title")

  expect(axiosMock.get).toHaveBeenCalledTimes(1);
  expect(axiosMock.get).toHaveBeenCalledWith(url);
 })

The first thing we do in our test is call our fake axios get request, and mock the resolved value with ironically the mockResolvedValue function offered by jest. This function does exactly what its name says, it resolves a promise with the data we pass in, which simulates what axios does.

This function has to be called before our render() function otherwise the test wont work. Because remember we are mocking the axios library itself. When our component runs the import axios from 'axios'; command it will be importing our fake axios library instead of the real one and this fake axios will be substituted in our component wherever we used axios.

Next we get our "...Loading" text node since this is what will be displayed before the promise resolves. After this we a function we havent seen before the waitForElement() function, which will wait until the promise resolves before going to the next assertion.

Also notice the await and async keywords, these are used in the exact same way as they are used in a non testing environment.

Once resolved the DOM node will have the text of "some title" which is the data we passed to our fake mock axios library.

Next we make sure the request was only called once and with the right url. Even though we are testing the url we didnt make an API request with this url.

And this is it for API requests with axios. In the next section we will look at e to e tests with cypress.

Cypress

Lets now go over cypress which I believe is the best framework to run e to e tests. We are now longer in jest land, we will now be working solely with cypress which has its own testing environment and syntax.

Cypress is pretty amazing and powerful. So amazing and powerful in fact that we can run every test we just went over in one test block and watch cypress run these tests in real time in a simulated browser.

Pretty cool, huh?

I think so. Anyway, before we can do that we need to setup cypress. Surprisingly Cypress can be installed as a regular npm module.

npm install cypress

To run cypress you will need to use this command.

node_modules/.bin/cypress open

If that seems cumbersome to write every time you want open cypress so you can add it to your package.json.

...

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "cypress": "node_modules/.bin/cypress open", 

   ...

this will allow you to open up cypress with just the npm run cypress command.

Opening up cypress will give you a GUI that looks like this.

To actually run the cypress tests, your app will have to be running at the same time, which we will see in a second.

Running the cypress open command will give you a basic configuration of cypress and create some files and folders for your automatically. A cypress folder will be created in the project root. We will write our code in the integration folder.

We can begin by deleting the examples folder. Unlike jest, cypress files take a .spec.js extension. Because this is a e to e test we will run it on our main App.js file. So you should have a directory structure that now looks like this.

We can also set a Base url in the cypress.json file. Just like this:

{ "baseUrl": "[http://localhost:3000](http://localhost:3000)" }

Now for our large monolithic test

import React from 'react';

describe ('complete e to e test', () => {
  it('e to e test', () => {
    cy.visit('/')
    //counter test
    cy.contains("Clicked: 0")
      .click()
    cy.contains("Clicked: 1")
    // basic hooks test
    cy.contains("Initial State")
    cy.contains("State Change Button")
      .click()
    cy.contains("Initial State Changed")
    cy.contains("Moe")
    cy.contains("Change Name")
      .click()
    cy.contains("Steve")
    //useReducer test
    cy.contains('stateprop1 is false')
    cy.contains('Dispatch Success')
      .click()
    cy.contains('stateprop1 is true')
    //useContext test
    cy.contains("Some Text")
    cy.contains('Change Text')
      .click()
    cy.contains("Some Other Text")
    //form test
    cy.get('#text1')
      .type('New Text {enter}')
    cy.contains("Change: New Text")
    cy.contains("Submit Value: New Text")
    //axios test
    cy.request('https://jsonplaceholder.typicode.com/posts/1')
      .should(res => {
          expect(res.body).not.to.be.null
          cy.contains(res.body.title)
        })
  });
});

As mentioned we are running every single test we just went over in one test block. I have separated each section with a comment so it will easier to see.

Our test may look intimidating at first but most of the individual tests will follow a basic arrange-act-assert pattern.

cy.contains(Some innerHTML text of DOM node)

cy.contains (text of button)
.click()

cy.contains(Updated innerHTML text of DOM node)

Since this is a e to e test you will find no mocking at all. Our app will be running in its full development version in a simulated browser with a UI. This will be as close to testing our app in realistic way as we can get.

Unlike unit and integration tests we do not need to explicitly assert some things. This is because some Cypress commands have built in default assertions. Default assertions are exactly what they sound like, they are asserted by default so no need to add a matcher.

Cypress default assertions

Commands are chained together so order is important and one command will wait until a previous command is completed before running.

Even when testing with cypress we will stick to our philosophy of not testing implementation details. In practice this is going to mean that we will not use html/css classes, ids or properties as selectors if we can help it. The only time we will need to use id is to get our form input element.

We will make use of the cy.contains() command which will return a DOM node with matching text. Seeing and Interacting with text on the UI is what our end user will do, so testing this way will be in line with our guiding principle.

Since we are not stubbing or mocking anything you will notice our tests will look very simplistic. This is good since this is a live running app, our tests will not have any artificial values.

In our axios test we will make a real http request to our endpoint. Making a real http request in an e to e test is common. Then we will check to see if that value is not null. Then make sure that the data of the response appears in our UI.

If done correctly you should see that cypress successfully ran the tests in chromium.

Continuous Integration

Keeping track and Running all these tests manually can become tedious. So we have Continuous Integration, A way to automatically run our tests continuously.

Travis CI

To keep things simple we'll just use Travis CI for our Continuous integration. You should know though that there are much more complex CI setups using Docker and Jenkins.

You will need to sign up for a Travis and Github account, both of these are luckily free.

I would suggest just using the "Sign Up with Github" option on Travis CI.

Once there you can just go on your profile icon and click the slider button next to the repository you want CI on.

So that Travis CI knows what to do we will need to configure a .travis.yml file in our project root.

language: node_js

node_js: 
  - stable


install:
  - npm install

script:
  - npm run test
  - npm run coveralls

This essentially tells Travis that we are using node_js, download the stable version, install the dependencies and run the npm run test and npm run coveralls command.

And this is it. You can know go on the dashboard and start the build. Travis will run the tests automatically and give you an output like this. If your tests pass you are good to go. If they fail, your build will fail and you will need to fix your code and restart the build.

Coveralls

coverall gives us a coverage report that essentially tells us how much of our code is being tested.

You will need to sign up to coveralls and sync with your github account. Similar to Travis CI, just go to the add repos tab and turn on the repo that you also activated on Travis CI.

Next go to your package.json file and add this line of code

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --coverage",
    "eject": "react-scripts eject",
    "cypress": "node_modules/.bin/cypress open", 
    "coveralls": "cat ./coverage/lcov.info | node node_modules/.bin/coveralls"
  },

Be sure to add the --coverage flag to the react-scripts test command. This is what will generate the coverage data that coveralls will use to generate a coverage report.

And you can actually see this coverage data on the Travis CI console after your tests have ran.

Since we are not dealing with a private repo or Travis CI pro, we dont need to worry about repo tokens.

Once your done you can add a badge to your repo README by copying the provided link on the dashboard.

It will look like this.

Conclusion

Count yourself among the top 20% of developers in terms of React testing skill if you made it through the entire tutorial.

Thanks for reading. cheers.

You can follow me on twitter for more tutorials in the future: https://twitter.com/iqbal125sf?lang=en

Further Reading

Blog Posts:

https://djangostars.com/blog/what-and-how-to-test-with-enzyme-and-jest-full-instruction-on-react-component-testing/

https://engineering.ezcater.com/the-case-against-react-snapshot-testing

https://medium.com/@tomgold_48918/why-i-stopped-using-snapshot-testing-with-jest-3279fe41ffb2

https://circleci.com/blog/continuously-testing-react-applications-with-jest-and-enzyme/

https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

https://willowtreeapps.com/ideas/best-practices-for-unit-testing-with-a-react-redux-approach

https://blog.pragmatists.com/genuine-guide-to-testing-react-redux-applications-6f3265c11f63

https://hacks.mozilla.org/2018/04/testing-strategies-for-react-and-redux/

https://codeburst.io/deliberate-practice-what-i-learned-from-reading-redux-mock-store-8d2d79a4b24d

https://www.robinwieruch.de/react-testing-tutorial/

https://medium.com/@ryandrewjohnson/unit-testing-components-using-reacts-new-context-api-4a5219f4b3fe

Kent C dodds Posts on Testing

https://kentcdodds.com/blog/introducing-the-react-testing-library

https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests

https://kentcdodds.com/blog/why-i-never-use-shallow-rendering

https://kentcdodds.com/blog/demystifying-testing

https://kentcdodds.com/blog/effective-snapshot-testing

https://kentcdodds.com/blog/testing-implementation-details

https://kentcdodds.com/blog/common-testing-mistakes

https://kentcdodds.com/blog/ui-testing-myths

https://kentcdodds.com/blog/why-youve-been-bad-about-testing

https://kentcdodds.com/blog/the-merits-of-mocking

https://kentcdodds.com/blog/how-to-know-what-to-test

https://kentcdodds.com/blog/avoid-the-test-user

Cheat Sheets / github threads

https://devhints.io/enzyme

https://devhints.io/jest

https://github.com/ReactTraining/react-router/tree/master/packages/react-router/modules/tests

https://github.com/airbnb/enzyme/issues/1938

https://gist.github.com/fokusferit/e4558d384e4e9cab95d04e5f35d4f913

https://airbnb.io/enzyme/docs/api/selector.html

Docs

https://docs.cypress.io

https://airbnb.io/enzyme/

https://github.com/dmitry-zaets/redux-mock-store

https://jestjs.io/docs/en

https://testing-library.com/docs/learning

https://sinonjs.org/releases/v7.3.2/

https://redux.js.org/recipes/writing-tests

https://jestjs.io/docs/en/using-matchers

https://jestjs.io/docs/en/api

This short article shares my experiences setting up my testing environment to unit test React Native components with Jest and Enzyme.

_Photo by [Unsplash](https://unsplash.com/photos/6wdRuK7bVTE?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Neil Soni on <a href="https://unsplash.com/search/photos/mobile-app?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Testing tools and environment

The first thing I learnt was the approach and infrastructure for writing unit tests for a React Native app are very similar to writing unit tests for a React app…perhaps unsurprisingly.

However, while the tooling and the use of the test suites are very similar, the testing environment and infrastructure have to be set up in a slightly different way. This is essentially because React apps are designed to work with the DOM inside a browser whereas mobile apps don’t target this data structure for rendering (they target actual ‘native’ modules that are on the mobile system instead).

Using Jest

Jest is a library used for testing JavaScript apps.

I wanted to use Jest for several reasons:

Firstly, it was created and is actively maintained by Facebook for their own React Native apps.

Secondly, it comes pre-packaged with the version of React Native I was working with (created using react-native).

Thirdly, Jest is a ‘comprehensive’ testing framework and contains the whole suite of testing tools I needed. For example, Jest comes with a library to check assertions, a test runner to actually run tests and tools to check code coverage. With other solutions, one has to choose and assemble individual components of a testing suite.

Using Jest + Enzyme

I wanted to combine Jest and Enzyme. There are lots of slightly confusing comments on the web that compare ‘Jest versus Enzyme’. This is a bit misleading. While Jest is a testing framework you can think of Enzyme as a library that makes it easier to select and query elements inside of an emulated DOM. So it is often used alongside Jest to make writing the logic of tests cleaner and easier to read.

Still confused? It’s similar to how jQuery introduced a concise and clear syntax for querying and selecting elements in the DOM, whereas the syntax using vanilla JavaScript was (at least back when jQuery was first introduced) not as clear and easy to use. And people don’t often compare ‘jQuery versus JavaScript’, unless they are comparing a particular way that the two approaches use to query and modify elements of the DOM.

Note: you can use Jest without Enzyme (I believe Facebook does this) but Enzyme makes your tests a bit easier to create and read. From my perspective, combining Enzyme with Jest is about convenience.

Setting up Jest + Enzyme

I had to jump through some hoops to successfully setup Jest and Enzyme in my React Native environment.

Jest now comes included with React Native apps created using the ‘react-native’ tool. So I could use Jest out of the box. Wonderful!

But I ran into some problems trying to combine Enzyme with React Native using their documentation. I never quite got to the bottom of what was the underlying problem, but I kept getting ‘modules not found’ errors like this one here.

A solution

In the end I used a solution that essentially abstracts away some of the setup into a pre-packaged environment using the jest-enzyme library and then made sure the jest ‘presets’ was set to ‘react-native’ in my package.json.

I followed the instructions to install these libraries:

npm install jest-environment-enzyme jest-enzyme enzyme-adapter-react-16 --save-dev

Errors when I tried to run my tests also directed me to explicitly install these myself too:

npm install --save-dev react-dom enzyme

Here is what I had to manually add to package.json:

// package.json before with react-native init

{
...
   "jest": {
       "presets": ["react-native"],
     }
...
}

// package.json after my manual changes:
{
...

"jest": {
       "presets": ["react-native"], // not clear in documentation!
       "setupTestFrameworkScriptFile": "jest-enzyme",
       "testEnvironment": "enzyme",
       "testEnvironmentOptions": {
           "enzymeAdapter": "react16"
       }  
   }
...
}

You can see the repo here.

Using the jest-enzyme library in this way worked easily for me and it also meant that I had a slightly cleaner setup. This is because the other approach (that I couldn’t get to work, following the Enzyme documentation) would have meant I also had to set up and maintain a separate ‘jest config’ script.

Summary

Writing business logic inside of Jest+Enzyme tests for React Native seems to be exactly the same as writing tests for React using Jest+Enzyme. This means the examples and documentation online for React unit testing are easily transferrable, which is really useful. This is a great step towards the vision of web developers being able to easily transfer their skills to create cross-platform mobile apps.

However, for the ease-of-use in the ‘test writing’ phase, I paid the price when setting up the infrastructure and environment so that the various tools were compatible with my React Native ecosystem.

In addition, from coming across Github issues in this area, it seems like there are lots of small instabilities between React Native versions that makes it really hard to find out what is the underlying cause of an infrastructure problem like the ones I described above. But I suppose we can’t have flexibility in such a fast-moving space as this without some challenges.

Here is the repo with my jest-enzyme setup with a few example tests.

I hope you found this interesting and useful! Please feel free to add any questions or comments below.

I recently made a simple ideas board web app using ReactJS, Ruby-on-Rails and PostgreSQL. Below, I’ll walk you through the initial steps I took to set up basic unit tests for one of the features of my app, adding a new idea.

_Photo by [Unsplash](https://unsplash.com/photos/awU3XEzdU94?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Dan DeAlmeida on <a href="https://unsplash.com/search/photos/ideas?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Note: I’m not going to discuss the scope of tests in this post; rather, my focus is on understanding how to install some of the dependencies in order to be able to get started with writing the tests.

Background: ideas board set up

I used Node package manager to manage my project’s dependencies. If you’d like to code along, you’ll need to make sure you have Node installed on your computer.

Project features

In Rails

Models: Idea

Relationships: none

In React

Components: Navbar, IdeasContainer, Idea

Getting started with RSpec

I used RSpec to test the Rails part of my ideas board web app. To get started:

1. I added the gem ‘rspec-rails’, ‘~> 3.8’ to my gemfile.

2. I then ran bundle in my terminal window (making sure I was in the Rails directory).

3. Next, in my Rails directory, I created a new folder called spec. And then, another new folder inside that one called requests.

4. I created a new file called ideas_spec.rb. You can replace the name ideas_spec with the name of whichever model you want to test, making sure to include the _spec part to denote that it's a test file.

5. At the top of my ideas_spec.rb file, I added the following text:

require ‘rails_helper’

6. Then, in the same file, I included code describing the first test I wanted to run:

describe “add an idea”, :type => :request dodescribe “add an idea”, :type => :request do
before do
 post ‘/api/v1/ideas’
end
it ‘returns a created status’ do
  expect(response).to have_http_status(201)
end
end

7. To run my test, I typed rspec in my terminal window, making sure I was in my rails project directory.

If you’ve been following along, RSpec should run at this point and your first test should pass!

Getting started with Jest

I was pleasantly surprised to find out that the testing framework Jest is included with create-react-app! However, I also wanted to use Enzyme, a testing utility, for which I needed to install some dependencies.

1. To start off, I created a new folder called _tests_ in my app’s src directory.
2. In my client-side directory, I ran the following commands:

npm i -D react-test-renderer

npm install --save-dev jest-enzyme

npm install --save-dev enzyme enzyme-adapter-react-16

3. To configure Enzyme, I created a file in src called setupTests.js and included the following:

const Enzyme = require('enzyme');
const EnzymeAdapter = require('enzyme-adapter-react-16');
Enzyme.configure({ adapter: new EnzymeAdapter() });

4. Inside my _tests_ folder, I created a new file, called App.tests.js

5. I included the following text at the top of this file to import my components and all the testing functionality I wanted for all my tests:

import React from 'react';
import App from '../App';
import Idea from '../components/Idea';
import IdeasContainer from '../components/IdeasContainer';
import { create, update } from 'react-test-renderer';
import '../setupTests';
import { shallow, mount, render } from 'enzyme';
import { shallowToJson } from 'enzyme-to-json';

6. Underneath, I included my first unit test:

describe('Idea', () => {
  it('should render a new idea correctly', () => {
    const output = shallow(
      <Idea
      key="mockKey"
      idea={"1", "Test", "Test"}
      onClick={"mockFn"}
      delete={"mockFn2"}
      />
    );
    expect(shallowToJson(output)).toMatchSnapshot();
  });
});

7. I ran rails s in the server side directory and then npm start in the client side directory to start my ideas board on localhost:3001.

8. To run my first test, I typed the following into my terminal window (making sure I was in the client directory):

npm run test

If you’ve been following along, Jest should run at this point, your test should pass — and you’re in a great place now to write more tests!

For more information on the ideas board project, my repo can be found here.

If you made it this far, thanks for reading! I hope my post helped you get started with setting up your tests.

Times and dates are infamously hard to correctly implement in code. This makes testing date and time code correctly important. Testing allows for reasoning around logic in code and also to allow catching edge cases or errors before they impact users.

A common mistake when testing date and time code is to not set the current time to a static time. If code in the UI renders today’s date and is tested properly, that test that only works until the current time changes too much. Javascript exposes the built-in Date object which allows for retrieving the current time through construction with no arguments or a call to the now() property.

Moment.js is a popular front-end date manipulation library that is commonly used to manipulate, load, format, and shift time. It uses an empty constructor to get the current time. Jest is often used in conjunction with Moment and React applications. Additionally, Jest snapshot testing introduces new dependencies on date and time that are important to consider. Below is an example problematic component that renders the current day:

An initial test for the TodayIntro component could look like:

However, this test will fail on any day that is not Jan 23rd. A solution to this is to override Javascript’s date function to return a known date to work against when writing tests.

This code overrides the Date constructor to set a static “current” date:

An ineffective solution is to do the date math yourself against the current time the test is run. This is an ineffective test because you’re running the same code you’re testing to test the return value. For instance, if testing by comparing formatted dates through moment, one would not catch if the moment formatting code changes MMM to JAN instead of Jan .

Ways to set a static time and timezone for Jest/JS

1. Use a library to mock out Date object to return a static date and timezone (we’d recommend MockDate for simple cases, but read on for a breakdown of the alternatives)
2. Mock moment().format() to return a static string
3. Mock the Date constructor and now() function to return a static time

Using a library in this case is preferable because these libraries are well tested, do not introduce boilerplate code and handle transparently both cases dates can be created (Date.now() vs new Date() etc.). Additionally, using a library allows for easily following test code and setting a specific time per test which allows for better testing practices.

• [MockDate](https://github.com/boblauer/MockDate) provides further functionality for time zones and is easy to use
• [sinon](https://sinonjs.org/releases/v7.2.4/fake-timers/) provides Date and timer (setTimeout etc.) mocks
• Manually setting the mock can be useful in limited environments, however, can become rather complicated
• [jasmine](https://jasmine.github.io/) (not included in jest), comes with a jasmine.clock()

The examples below use MockDate, which only focuses on mocking the Date object simply and handles testing time zone offsets as well for testing local time zone conversion.

A snapshot test, as well, is simple to test with mocked dates:

Since enzyme is an awesome library, an enzyme shallow example:

How to (better) test date logic

Dates have a lot of edge cases and logic behind them. When testing dates, make sure to cover edge cases and not just set one specific date to test and move on. Dates can also vary according to locale and time zone.

Properly testing dates require reasoning around edge cases that could occur and writing tests to ensure those edge cases behave as expected and that future changes to code or libraries used in your application don’t break those assumptions. Additionally, adding code to set the current date and time to a static date and time across all test code may be easier, but prevents good reasoning around testing Dates and hides test assumptions in library code.

Here are a few incorrect and often implicit assumptions about dates:

1. Clients all exist within one time zone and daylight saving time
2. All clients exist within the developer’s time zone
3. The length of a Month name is relatively similar
4. Server clocks are always correct
5. The server knows the client’s timezone/time settings

This test assumes the server is always in the correct timezone and that timezone is set correctly. Instead, set the timezone and make sure the date matches the local timezone correctly.

It is important to ensure that when tests access the current time the “current time” is set to a static value. If the value is dynamic, either tests eventually break or a test is testing against dynamic values. Dynamic values are not effective at testing behavior since a bug will not be exposed by comparing the return value of two functions that are the same as compared to comparing to a static value that doesn’t change as the code is modified.

Looking ahead: Date time storage and design

Having a requirement to add tests to a code base doesn’t necessarily provide any value unless those tests are reviewed, run, and reasoned about just as strictly as running code.

Date and time logic introduces a large set of possibilities in terms of behavior and output, making a strong incentive to test effectively for date and time. Beyond testing, acknowledging and keeping relevant data along with a strategy to synchronize and store date times consistently across systems early on both helps testing and makes for a better user experience.

These tips and approaches apply to more than just Javascript & Jest testing for dates and times. They also work in a NodeJS context and in a general sense around key things to test for in systems that handle date and time in general. In many cases, storing time on the server in UTC (Universal coordinated time) then converting to the local time zone based on client / browser settings is ideal. If the client is inaccessible, storing both the UTC time and user’s actual timezone is an effective way to consistently treat dates and times.

This article is a simple walkthrough of how to apply Test Driven Development (TDD) principles to a JavaScript exercise using Jest.

Intro

After a few years of experience developing on my own personal projects, I recently decided to become a Full-Stack developer.

This new situation encouraged me to start thinking about practices that I’ve neglected until now, such as testing my code.

That is why I wanted to start my journey through Test Driven Development. I’ve decided to share my first steps here with you.

The exercise

I decided to start with the first Osherove TDD kata. You can access the full exercise here.

The goal is to deliver a function that takes a string entry ("1, 2, 3" for instance) and returns the sum of all numbers.

Our project will have the following structure:

js-kata-jest/

├─ src/

  └─ kata.js

├─ test/

  └─ kata.test.js

└─ package.json

Setting up the test environment

First we have to set up the test environment. As a React developer, I decided to go with Jest. You may use any other testing library of your choice.

Installing Jest dev dependency

yarn add --dev jest

or with npm:

npm install --save-dev jest

Activating Jest on your code editor

I am using Atom as a code editor, and installed the tester-jest package. This allowed me to run my tests on save for any *.test.js file.

Test Driven Development

The theory behind TDD is quite simple, and revolves around 3 steps:

1. Writing a test for a small part of a functionality and checking that this new test is failing (Red step)
2. Writing the code that makes the test pass, then checking that your previous test and the new one are successful (Green step)
3. Refactoring the code to make sure it is clear, understandable, and behaves well with the previous functionalities

In the next part, we are going to go into detail for each of these steps.

Solving the exercise

First loop

First, we want to handle the case where our add function is given an empty string or one with a single element.

1. Writing the tests

2. The first test checks that an empty string returns 0

3. The second checks that a single element string returns the provided element

2. Writing the code

• First we return 0 by default
• Then we provide an if statement that handles the parsing of a single provided element

Here is the final code:

3. Refactoring the code

As it is our first functionality, we can skip this step for now — but we will soon return to it. ;)

Second loop

We will now handle the case where the string contains multiple elements:

1. Writing the tests

The new test makes sure that calculation of a multiple element string was done correctly:

2. Writing the code

• First we create a new if statement on purpose to be sure that our first two tests affect the new solution
• Second we create a new array from the entry string, using the , as a separator
• Finally, we parse each element of the newly created array to calculate the sum

Here is the final code:

3. Refactoring the code

As we can see above, there are several problems within our code:

• the two if statement shouldn’t be decorrelated, as adding one or more to zero should behave the same.
• the separator value is drowned in the code. This adds complexity if we want to change to a ; separator, for instance.
• a large part of our code is located in an if statement. We could reverse the logic to extract our main code from it.

So we can add a new separator variable, which will decide on the separator type. We can also merge the two if statement into one, and then reverse the logic.

We can now run our test again before moving on to the next loop.

Third loop

We can now handle the declaration of new separators and avoid the entry of negative numbers.

1. Writing the tests

2. The first new test focuses on a single separator within the default values.

3. The second will make sure that we can configure a new separator directly within the input.
4. The third one will check that an error is thrown when a negative value is passed as an entry.

2. Writing the code

• First, we replace the separator string by a separators array, where we add the \n value.
• Second, we introduce a new separator search through a regular expression. That will be added to the previous array.
• We can now join the previous array elements to split the string with them.
• We filter the resulting array to remove all non-number elements.
• We add a new array, negatives, that will spot negative values within the entry.
• If the negatives array isn’t empty, throw an error.

Here is the final code:

3. Refactoring the code

We now have two new possible optimizations:

• We are using the regular expression twice, and are willing to change it easily. We can extract it within a new const regexp.
• We calculate parseInt(list[i])several times, so we should store the value only once to speed up the for loop.

Conclusion

We can now run our tests again to make sure that all our expected functionalities are still working.

You may now continue on your own as well. Check out the definitive version of the kata with all tests passing here.

Feel free to reach me on Twitter if you have any questions or comments @nclsmitchell or through Medium :)

Thanks for your reading, and please clap for me if you like this post.