Sometimes you may have situations where configuration needs to be different for certain tests. In this lesson we’ll take a look at how we could create a custom configuration for tests that are intended to run in a node environment.

Configure Jest for Testing JavaScript Applications

Run Tests with a Different Configuration using Jest’s --config Flag and testMatch Option

Instructor: [00:01] Let's imagine a scenario where we want to be able to run some of our code on the server side. For example, maybe autoscaling text. We want to make sure that can run on the server.

[00:10] To do that with any amount of confidence, we want to have a test that runs only on the server side with no js to on setup, like we have for our existing test. Maybe I'd add a server test directory here, and we have autoscalingtext.js.

[00:25] This would be the kind of test in here, so we'd use reactyDOMServer to render it to string, just to make sure that things are going to render. We'll make sure we only run this file in the node environment, rather than the js.dom environment.

[00:38] Let's go ahead and make that work. We're going to have to re-work a few things, so I'm going to go down here to our test directory. We're going to actually move this jest-config.js to our test directory.

[00:50] I'm actually going to change this from jest.config to jest.common, because this is going to be the common configuration between the server side and the client side versions of our configuration. I'm going to add a jest.client.js file here. We'll have a jest.server.js file in the test folder.

[01:08] Let's do the server side first. We're going to do module.exports. We're going to want pretty much all the same things from require/jest/common, but we're going to override the coverage directory because we don't want this coverage directories writing over each other.

[01:22] This one will be in path.join.dirname. This will be one directory app in the coverage directory under a server directory. We're going to need the path module require path from Node. Next, we're going to want to have a test environment set up here. This is going to be jest environment Node. That's the important part here.



[01:47] We need to make sure we can find this particular test. We're going to say all of our server tests are going to be under a directory called server_test here. We'll just match that with a test match that is a globe that is **/server test/**/*.js. Anything inside of a directory like that.

```js
const path = require('path')

module.exports = {
  ...require('./jest-common'),
  coverageDirectory: path.join(__dirname, '../coverage/server'),
  testEnvironment: 'jest-environment-node',
  testMatch: ['**/__server_tests__/**/*.js'],
}
```

[02:09] On our client side, it's going to be basically the same type of thing. We'll say module.exports = this object. We'll spread all of the things that we get from our jest common. We'll add the test environment to the Jest environment Jest DOM. We'll just be explicit about that. Then we'll have a couple other configurations from our jest common.

[02:34] Actually, I'm happy with having the module directories in here. I don't want the test environment to be specified in here. The module name mapper is fine to stay common, but the senate files after ENV and the snapshot serializers, we're going to make those specific to the client side. Let me paste those over here.

[02:50] We're going to want the coverage threshold to be for the client only. We'll move that into our client here as well. In our Jest common, we need to update a couple paths here.

```js
module.exports = {
  ...require('./jest-common'),
  testEnvironment: 'jest-environment-jsdom',
  setupFilesAfterEnv: ['@testing-library/jest-dom/extend-expect'],
  snapshotSerializers: ['jest-emotion'],
  coverageThreshold: {
    global: {
      statements: 15,
      branches: 10,
      functions: 15,
      lines: 15,
    },
    './src/shared/utils.js': {
      statements: 100,
      branches: 80,
      functions: 100,
      lines: 100,
    },
  },
}
```

[03:02] The style mock is relative to where this file is. We no longer need to specify test here. This path join dir name actually can now just be dir name because we are in the test directory now. The path to the source is one directory up. We'll put that there.

```js
const path = require('path')

module.exports = {
  moduleDirectories: [
    'node_modules',
    path.join(__dirname, '../src'),
    'shared',
    path.join(__dirname),
  ],
  moduleNameMapper: {
    '\\.module\\.css$': 'identity-obj-proxy',
    '\\.css$': require.resolve('./style-mock.js'),
  },
  collectCoverageFrom: ['**/src/**/*.js'],
}
```

[03:18] And then we can tell Jest to use these different configurations on the command line. I can say npxjestconfigtest/jest.client.

```bash
npx jest --config test/jest.clients.js
```

That will run my client tests. We have one problem here. That is when we specify, "Hey, Jest, I want you to run the configuration that's found in this file," then Jest will look for all tests that match the test match in the same place where the Jest config is found.

[03:45] We need to specify, "No, no, no. We want the root directory root dir to be path.join dir name, one path up." 

```js
const path = require('path')

module.exports = {
  rootDir: path.join(__dirname, '..'),
  moduleDirectories: [
    'node_modules',
    path.join(__dirname, '../src'),
    'shared',
    path.join(__dirname),
  ],
  moduleNameMapper: {
    '\\.module\\.css$': 'identity-obj-proxy',
    '\\.css$': require.resolve('./style-mock.js'),
  },
  collectCoverageFrom: ['**/src/**/*.js'],
}
```

If we take a look at that whole thing here, we want the root directory where you're going to be looking for your tests to be one path, one directory up from where you are currently, which is in this test directory.

[04:06] We're going to make the root directory right here, which is where it was before. We had to be explicit about it because our configuration is found in the test directory here.

[04:14] Now if we run that same script again, 

```bash
npx jest --config test/jest.clients.js
```

We are going to get all of our tests found, all of our tests run. We can do the same thing for the server side as well. 

```bash
npx jest --config test/jest.server.js
```

At least we could if we didn't have a syntax error.

[04:25] Let's go ahead and fix that little problem there. We'll run this again for our server side tests. Great. We can verify that our server side tests are indeed running in a totally browser-free environment by `console.log(window)`. This is going to throw us an error because window is not defined.

[04:44] Great. Now we verified that this can function inside a browser environment or outside of a browser environment, which was our original goal.

[04:51] Now we have to update our package JSON to have a silly amount of scripts to make this work. I'm going to copy and paste those to save us a ton of time. We'll get rid of all that, paste these in.

```js
{
  "name": "calculator",
  "version": "2.0.0",
  "description": "See how to configure Jest and Cypress with React, Babel, and Webpack",
  "main": "index.js",
  "scripts": {
    "test": "is-ci \"test:coverage\" \"test:watch:client\"",
    "test:coverage": "npm run test:coverage:client && npm run test:coverage:server",
    "test:coverage:client": "jest --config test/jest.client.js --coverage",
    "test:coverage:server": "jest --config test/jest.server.js --coverage",
    "test:watch:client": "jest --config test/jest.client.js --watch",
    "test:watch:server": "jest --config test/jest.server.js --watch",
    "test:debug:client": "node --inspect-brk ./node_modules/jest/bin/jest.js --config test/jest.client.js --runInBand --watch",
    "test:debug:server": "node --inspect-brk ./node_modules/jest/bin/jest.js --config test/jest.server.js --runInBand --watch",
    "dev": "webpack-dev-server --mode=development",
    "build": "webpack --mode=production",
    "postbuild": "cp ./public/index.html ./dist/index.html",
    "start": "serve --no-clipboard --single --listen 8080 dist",
    "format": "prettier --ignore-path .gitignore --write \"**/*.+(js|json|css|html|md)\"",
    "lint": "eslint --ignore-path .gitignore .",
    "validate": "npm run lint && npm run test && npm run build",
    "setup": "npm install && npm run validate"
  },
  ```

[05:03] Now, our test script is going to run test coverage. The test coverage script runs the coverage for the client and then the server. Our watch mode is actually only going to run the client side watch mode, because we can't run two watch modes at once, but you could explicitly run the server watch mode if you want to.

[05:19] We have a debug for the client and server as well. We have duplicate scripts for each one of these where we're specifying the configuration to the client and the server.

[05:29] One last thing we need to do to make sure everything's working properly is update our eslintrc, so it's pointing to our jestcommon, which is found in the test directory.

```js
{
            jestConfigFile: path.join(__dirname, './test/jest-common.js'),
          },
        },
```

Now, if we run `npm run test`, that'll start our client-side tests in watch mode.

[05:45] If we run `CI=1 npm t` to run our tests, it'll run both client, and our server-side tests with coverage turned on.

[05:53] In review to make all of this magic happen, we moved our configuration to this jestcommon under tests. Then, we moved a lot of that into jest.client for all the jest client-specific stuff and mixing in the jest common stuff here.

[06:08] Then we created a jest server which mixes in those common things and overrides a couple so that we can have some server tests throughout our codebase. Then, we updated our package json to use jest with the config flag to specify which one of these configurations we want each script to be running.

[06:24] Then, finally, we updated our eslintrc so that jestconfig file is pointing to that common file so that eslint can resolve our modules properly.


Jest is a fully featured testing framework with a developer experience that is second to none. It’s remarkably simple and flexible at the same time. For simple use cases, you often don’t need to configure anything, install and enjoy the built-in coverage and watch mode support.

In a real-world application though, you’ll often have needs specific to your application, especially when testing browser-based applications. You'll need to handle Webpack loaders, dynamic imports, and custom module resolution which Node.js does not support.

In this course we’ll go over ways you can optimize your Jest configuration to make testing real-world JavaScript applications a delight. We’ll cover what’s already been mentioned in addition to Babel support, code coverage, how to make watch mode even more helpful, and how to run test suites with entirely different configurations.

Intro to Configure Jest for Testing JavaScript Applications

We start in a small, but real-world application that’s built with webpack and React. We’ll go over installing the Jest testing framework locally to our project, adding an npm script to make it easy to run, and adding an example test file.

Install and Run Jest

Jest automatically loads and applies our babel configuration. However, because our project takes advantage of tree shaking with webpack, our babel configuration disables compiling modules. For Jest to work on our code, we need to make sure that our babel configuration compiles modules during our tests. We’ll use the NODE_ENV environment variable to generate the proper configuration.

Compile Modules with Babel in Jest Tests

In our application we’re testing code that should run in the browser, but Jest is intended to test JavaScript that runs in the browser or in node. Let’s create a custom jest config file so we can customize the test environment.

Configure Jest’s Test Environment for Testing Node or Browser Code

In most real-world applications using webpack, you’re likely using a few loaders. In this lesson we’ll see how to make Jest load our modules properly with a moduleNameMapper so we can test our code that makes use of these loaders.

Support Importing CSS files with Jest’s moduleNameMapper

If you’re using CSS modules with webpack, then we can improve our moduleNameMapper to improve our experience and capabilities testing our components by including the css module property name in our tests using identity-obj-proxy.

Support using Webpack CSS Modules with Jest

Snapshot testing is a way to simplify writing and maintaining assertions. As noted in [the Jest documentation](http://jestjs.io/docs/en/snapshot-testing.html#snapshot-testing-with-jest): “The snapshot artifact should be committed alongside code changes, and reviewed as part of your code review process. Jest uses pretty-format to make snapshots human-readable during code review. On subsequent test runs Jest will simply compare the rendered output with the previous snapshot. If they match, the test will pass. If they don't match, either the test runner found a bug in your code that should be fixed, or the implementation has changed and the snapshot needs to be updated.” Let’s see how these work and in what situations we can and should use them.

This lesson uses a simple demo before hopping into the application code testing DOM nodes. This example code isn't available.

Generate a Serializable Value with Jest Snapshots

Part of the power of snapshots is the ability to provide custom serializers. Let’s check out how to use jest-emotion to include our emotion CSS styles in our React component snapshots so we can be made aware of the impact of our CSS changes on our components.

UPDATE: `jest-emotion` has been renamed to `@emotion/jest` and you add the serializer with `'@emotion/jest/serializer'` instead of simply `'jest-emotion'`.

Test an Emotion Styled UI with Custom Jest Snapshot Serializers

Webpack’s resolve.modules configuration is a great way to make common application utilities easily accessible throughout your application. We can emulate this same behavior in Jest using the moduleDirectories configuration option.

Support Custom Module Resolution with Jest moduleDirectories

Often you’ll have some setup that you want to run before your tests start. Let’s see how we can use the setupFilesAfterEnv configuration in Jest to take care of test boilerplate and establish a good testing environment for our tests.

Configure Jest to Run Setup for All Tests with Jest setupFilesAfterEnv

Every large testbase has common utilities that make testing easier to accomplish. Whether that be a custom render function or a way to generate random data. Let’s see how we can make accessing these custom utilities throughout the tests easier using Jest’s moduleDirectories feature.

Support a Test Utilities File with Jest moduleDirectories

As the codebase grows it makes our test runs take longer and longer. Naturally people will run the tests less frequently to avoid waiting. With Jest’s powerful and interactive watch mode we can easily run the tests that we want to focus on without having to run all the tests in the codebase.

Use Jest Watch Mode to Speed Up Development

Sometimes it can be a real challenge to determine what’s going on when testing your code. It can be really helpful to step through your code in a debugger. In this lesson we’ll see how to use Jest’s --runInBand flag with node’s --inspect-brk to debug our tests in Chrome’s debugger.

Step through Code in Jest using the Node.js Debugger and Chrome DevTools

Jest comes with code coverage reporting built-into the framework, let’s see how quick and easy it is to add code coverage reporting to our project and take a look at the generated report. 

Configure Jest to Report Code Coverage on Project Files

You may have an idea of what Code Coverage is, but let’s take a quick look at how it’s recorded so we can understand how to analyze code coverage reports.

Analyze Jest Code Coverage Reports

Wherever you are at with code coverage you generally don’t want that level to go down. Let’s add coverage thresholds globally as well as in specific files to ensure we never drop below a certain level of coverage.

Set a Code Coverage Threshold in Jest to Maintain Code Coverage Levels

The coverage report generated by Jest is fantastic, but it’d be great to track that coverage over time and be able to review that coverage at a glance, maybe even put it up on a display in the office! Codecov.io is a fantastic service that can consume our code coverage report and it integrates great with GitHub. Let’s see how we can extend our existing Travis build configuration to send the coverage report to Codecov.io.

Report Jest Test Coverage to Codecov through TravisCI

In CI, we don’t want to start the tests in watch mode, but locally we normally want to run the tests in watch mode. We can have separate scripts, but it’d be great to not have to remember which script to run locally. Let’s use is-ci-cli to run the right script in the right environment when running the test script.

Run Jest Watch Mode by Default Locally with is-ci-cli

Sometimes you may find it useful to have more than one configuration in a project (for example, running some tests in a node environment and others in the jsdom environment). In this lesson we’ll learn about Jest’s projects feature to have jest run both of these configurations at once.

Support Running Multiple Configurations with Jest’s Projects Feature

Jest is more than a testing framework. It’s a highly optimized, blazing fast platform with incredible parallelization for running tasks across many files in our project. It has a capability to run more than just tests. We can bring these features to our linting as well. Let’s see how we can bring our favorite Jest features (like watch mode) to ESLint with jest-runner-eslint.

Run ESLint with Jest using jest-runner-eslint

It’s great that we can run multiple projects in our watch mode and that we can scope the tests down to specific tests, but sometimes it’s nice to be able to quickly switch between projects in watch mode. Let’s see how this works with jest-watch-select-projects.

Test Specific Projects in Jest Watch Mode with jest-watch-select-projects

Jest’s watch mode is [pluggable](http://jestjs.io/docs/en/watch-plugins.html) and jest-watch-typeahead is one plugin that you definitely don’t want to live without. It enhances the watch mode experience to help you know which tests will be run based on your filter. Making it even easier to run only the tests you’re concerned with running as you develop your codebase.

Filter which Tests are Run with Typeahead Support in Jest Watch Mode

Running the project tests on commit is a great way to avoid breaking the application accidentally and leverage the mechanism for confidence you have from your testbase. However, as the testbase grows this can take a very long time and slow productivity down. Let’s see how Jest is capable of running only the tests and linting only the files that are affected by the files we’re committing with husky and lint-staged to speed up our local test runs as well as help us avoid accidentally committing code that breaks our application.

Run Tests with a Different Configuration using Jest’s --config Flag and testMatch Option

Transcript

Run Tests with a Different Configuration using Jest’s --config Flag and testMatch Option