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.

Configure Jest for Testing JavaScript Applications

Analyze Jest Code Coverage Reports

Instructor: [00:01] As you're reviewing a coverage report, you might wonder to yourself, "OK. How in the world does Jest know that this part of the code is not being run in my test? That's just some magic going on here."

```js
if (match) {
  formattedValue += /[1-9]/.test(match[0]) ? match[1] : match[0]
}
```

[00:13] It's not magic. This is actually using a tool called `babel-plugin-istanbul` to instrument your code for coverage. I want to show you how this works. Here is our utils file that has that match that's not being covered.

```js
function getFormattedValue(value, language = 'en-US') {
  let formattedValue = parseFloat(value).toLocaleString(language, {
    useGrouping: true,
    maximumFractionDigits: 6,
  })

  // Add back missing .0 in e.g. 12.0
  const match = value.match(/\.\d*?(0*)$/)

  if (match) {
    formattedValue += /[1-9]/.test(match[0]) ? match[1] : match[0]
  }
  return formattedValue
}

export {getFormattedValue}
```

[00:26] This is what the file looks like in your source, but Jest doesn't run this file when it's running your test under coverage. It actually transforms this file using Babel into something that looks more like this.

```js

var cov_2k0r47ewe = function () {
  var path = "/Users/kentcdodds/Desktop/tmp/utils.js";
  var hash = "797a9fb26f3bf326cd604591b0f8e666e1afc48e";
  var global = new Function("return this")();
  var gcv = "__coverage__";
  var coverageData = {
    path: "/Users/kentcdodds/Desktop/tmp/utils.js",
    statementMap: {
      "0": {
        start: {
          line: 2,
          column: 23
        },
        end: {
          line: 5,
          column: 4
        }
      },
      "1": {
        start: {
          line: 7,
          column: 16
        },
        ...
```

[00:39] Not a whole lot of this looks the same until we get down here to line 205 where it starts looking kind of the same.

```js
function getFormattedValue(value, language = (cov_2k0r47ewe.b[0][0]++, 'en-US')) {
  cov_2k0r47ewe.f[0]++;
  let formattedValue = (cov_2k0r47ewe.s[0]++, parseFloat(value).toLocaleString(language, {
    useGrouping: true,
    maximumFractionDigits: 6
  }));
  const match = (cov_2k0r47ewe.s[1]++, value.match(/\.\d*?(0*)$/));
  cov_2k0
```

We've got that get formatted value, but we also have all of this other extra stuff going on in here.

[00:52] What is all this plus, plus nonsense? Well, what's going on here is we have this `var cov_2k0r47ewe` stuff here going on, whatever that is. It's this variable that's being declared through this immediately invoked functioning expression. Here we have a path, we have a file hash and a whole bunch of other information.

[01:11] What's particularly of note is this `coverageData` object.

```js
var coverageData = {
  path: "/Users/kentcdodds/Desktop/tmp/utils.js",
  statementMap: {
    "0": {
      start: {
        line: 2,
        column: 23
      },
    ...
```

This is going to have a map for all the statements. It's going to have a map for the functions and branches. Branches are interesting because each one of them is going to have a start and an end and any location as well for each one of the branches, the left and the right side of our branch.

[01:34] We have if statements and we also have our conditional expressions or the ternaries. The ternary is the part that we're not getting coverage on. If we come down here to our code, we're going to see we have this `getFormattedValue`, we have a `value` here and then our `language`.

```js
function getFormattedValue(value, language = (cov_2k0r47ewe.b[0][0]++, 'en-US')) {
  cov_2k0r47ewe.f[0]++;
  let formattedValue = (cov_2k0r47ewe.s[0]++, parseFloat(value).toLocaleString(language, {
    useGrouping: true,
    maximumFractionDigits: 6
  }));
```

[01:52] The default expression here is actually a branch. The first array is the first branch in our code (`cov_2k0r47ewe.b[0][0]++`). This is the first side of the branch and that is going to be incremented one time and then the completion value of this entire expression, which is using the comma operator right there is going to be this `en-US`.

[02:10] It's not actually changing the behavior of your code, it's just adding some instrumentation so that it can keep track of the side of the default value expression run. Here (`cov_2k0r47ewe.f[0]++;`), we are incrementing the function because we know now OK if this line runs, we know that the function has been run.

[02:27] Now, this is an expression here with `formattedValue` where we're assigning a value to a variable, so we're going to keep track of that statement.

```js
let formattedValue = (cov_2k0r47ewe.s[0]++, parseFloat(value).toLocaleString(language, {
    useGrouping: true,
    maximumFractionDigits: 6
  }));
```

We also have a statement here, so we're going to keep track of that one.

```js
const match = (cov_2k0r47ewe.s[1]++, value.match(/\.\d*?(0*)$/));
  cov_2k0r47ewe.s[2]++;
```

Here we have a conditional expression, so it's a branch. This is our second branch. The first side of the branch and our second branch on this side and that's the second side of the branch.

```js
if (match) {
    cov_2k0r47ewe.b[1][0]++;
    cov_2k0r47ewe.s[3]++;
    formattedValue += /[1-9]/.test(match[0]) ? (cov_2k0r47ewe.b[2][0]++, match[1]) : (cov_2k0r47ewe.b[2][1]++, match[0]);
  } else {
    cov_2k0r47ewe.b[1][1]++;
  }
```

[02:48] What's interesting about this is in our original code, we actually don't have an `else` case of this `if`. For them to make sure that we cover a situation where the `if` statement actually isn't run, they add an `else` case for us.

[03:00] Again, not changing the actual behavior of the code, just instrumenting it so they can keep track of what is going on as our code is being run in the test. The interesting part here is in our code coverage report we're not hitting this match at one, we're actually only hitting the match at zero.

```js
formattedValue += /[1-9]/.test(match[0]) ? (cov_2k0r47ewe.b[2][0]++, match[1]) : (cov_2k0r47ewe.b[2][1]++, match[0]);
```

[03:18] What we're getting right here is this match at one. What's happening is because this, `(cov_2k0r47ewe.b[2][0]++, match[1])`, expression is never evaluated, this branch, our third branch, the first side of that branch is never getting incremented. That's how it knows that we're never running this code because that entry for this branch is never getting incremented.

[03:36] Understanding this can really help you analyze this report. It can also help you in determining how you can ignore certain parts of your code from coverage because babel-plugin-istanbul actually allows you to ignore some of this.

[03:49] If we add an `/* istanbul ignore next */`, then it basically says, "Hey, istanbul. This isn't actually all that important, so I'm just going to ignore this part of coverage."

```js
function getFormattedValue(value, language = 'en-US') {
  ...

/* istanbul ignore next */
  if (match) {
    formattedValue += /[1-9]/.test(match[0]) ? match[1] : match[0]
  }
  return formattedValue
}
```

With that, we wind up with this kind of situation where it leaves that part of the code alone.

[04:05] It keeps our comment in here, but it doesn't add the branch, it doesn't add any of the instrumentation here. What you're left with is 100 percent code coverage for this because no coverage is being recorded for this branch.

```js

function getFormattedValue(value, language = (cov_2k0r47ewe.b[0][0]++, 'en-US')) {
  cov_2k0r47ewe.f[0]++;
  let formattedValue = (cov_2k0r47ewe.s[0]++, parseFloat(value).toLocaleString(language, {
    useGrouping: true,
    maximumFractionDigits: 6
  }));
  const match = (cov_2k0r47ewe.s[1]++, value.match(/\.\d*?(0*)$/));
  /* istanbul ignore next */

  if (match) {
    formattedValue += /[1-9]/.test(match[0]) ? match[1] : match[0];
  }

  cov_2k0r47ewe.s[2]++;
  return formattedValue;
}
```

[04:18] I typically recommend against using these kinds of comments because you're basically lying to yourself about how much coverage you're getting, but sometimes it can be useful.

[04:27] Hopefully understanding how your code is being instrumented for coverage will help you interpret these reports better, so that you can improve that code coverage of your application.


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

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 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.

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

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.

Analyze Jest Code Coverage Reports

Transcript

Analyze Jest Code Coverage Reports