The Jest Config File

Configuration methods

Jest accepts the following three methods for its configuration:

• Write the settings directly in the application’s package.json file.
• Write the settings in jest.config.js or jest.config.ts, and place the file in the application root.
• Write the settings in any file and identify the path/name with the CLI flag.

The package.json file

In this method, we only need to add the jest key at the top level of our application’s package.json file and point it to a JSON object of Jest configuration options. This option is illustrated below:

{
  name: "my-app",
  version: "0.1.0",
  jest: {
    clearMocks: true,
    rootDir: "./"
  }
}

The jest.config.js or jest.config.ts file

A separate configuration file is preferred. In this route, we add either a jest.config.js or jest.config.ts file to the root of our application and include all configuration options here. This would look like the following:

/// jest.config.js

module.exports = {
  clearMocks: true,
  rootDir: "./"
};


/// jest.config.ts (with ts-node installed)
import type { Config } from '@jest/types';

export default {
  clearMocks: true,
  rootDir: "./"
} as Config.InitialOptions;

The CLI flag

Last, we can include our configuration in a file with a name and location of our choosing. The file would look similar to the example in the previous method. However, it can be a JavaScript, TypeScript, CommonJS, ES Module, or JSON file type.

/// myJestConfiguration.json

{
  clearMocks: true,
  rootDir: "./"
};

We tell Jest where to find the configuration with its CLI flag, as shown below:

yarn jest --config myJestConfiguration.json

Popular configuration options

For this section, we’ll work inside the context of a jest.config.js file.

Jest offers a robust set of configuration options, allowing us to control everything from setting up testing coverage reports to globals to setup and teardown. We can structure Jest to the specific needs of our application. We are going to cover several popular configuration options in depth and include a complete list below with brief descriptions.

clearMocks: This is of the boolean type, and its default is false. We will dive deep into mocks at a later point, but we only need to know two things for now:

• Mocks are a tool for controlling and replicating certain behavior, such as an API call or a third-party SDK. These API calls or third-party SDKs will either not work in a testing environment by nature, or their functionality is not something that should affect the outcome of a test.

• Mocks do not reset on each use, meaning that if we mock a specific API call response once, that response will be active until specifically cleared.

Typically, it’s a best practice to keep each individual test isolated from the others. Eventually, one of our tests will fail, and we want to know that we only need to look at exactly what happened inside the test. Anyone who has spent hours debugging a test only to realize that a mock from three tests above is still in place knows how important it is to clear our mocks.

collectCoverage: This is of the boolean type, and its default value is false.

Testing coverage requires a few other fields as well to properly set up, but when configured properly, it can tell us exactly which statements, branches, functions, and lines of code are currently being tested, and which are not. This is an absolute must-have.

testEnvironment: This is of the string type, and its default value is node. JavaScript is incredibly versatile and is able to run in so many different environments thanks to Node. However, this flexibility comes at a cost, and sometimes it is useful to reign it in a bit.

Testing a server-side Express application will look entirely different from testing a Vue web application. Querying the DOM on the server should always fail, even if the code is valid. Alternatively, in a client we’ll need to suspend reality and allow this even in our tests outside the browser.

We can accomplish this through the testEnvironment option, which, by default, is set to node but can be set to jsdom for browser simulation.

testURL: This is of the string type, and its default value is http://localhost. It’s a client-side specific option that allows us to specify a consistent URL to be used as our application’s domain during testing. In any tests in which we are parsing the URL or working with the location variable, we’ll know to test for the presence of the string specified here.