9 JEST Configuration Parameters for testing your React App

In the previous blog, JEST – A De Facto Unit Testing Platform for ReactJS, the focus was on deciding on a React testing framework. Comparisons were made between different testing frameworks over multiple parameters and concluded that JEST is a De Facto for unit testing a React application.

Now, this article articulates the flexibility and strength provided to developers by JEST.

A Sneak Peek into Configurational Parameters!

JEST has more than 50 configurational parameters that a developer can work with and which can be changed as per the requirements. Hence, a few important configurational parameters are explained below that are used by our team to successfully achieve unit testing in our projects.

1. bail [Boolean] (Default: false)

• The bail configuration option can be used to have Jest stop running tests after the first failure.
• By default, Jest runs all tests and produces all errors in the console upon completion.
• This feature is useful for the production environment where even the failure of one test case will halt the complete deployment process.

2. moduleNameMapper [Object] (Default: null)

• This configuration holds the key to file mocking.
• By using this configuration all the external asset files like images and style files will be mocked, as these files are not intended to be tested. So, while running test cases, only the mock files are imported.
• Example:

“moduleNameMapper”: {
      “\\.(css|scss)$”: “<rootDir>/tests/mocks/styleMock.js”,
      “\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4)$”:
		"<rootDir>/tests/mocks/fileMock.js"
 },

Example of styleMock :

const mockStyle = {};
export default mockStyle;

Example of fileMock :

const mockFile = ‘test-file-stub’;
export default mockFile;

3. setUpFiles [Array] (Default: [])

• With this configuration, global JavaScript variables like document and window can be manually configured.
• Since every test runs in its own environment, these scripts will be executed in the testing environment right before executing the test code itself.
• Example:

“setupFiles”: [
	"<rootDir>/tests/mocks/documentMock.js"
],

Set Up Files Example:

“Object.defineProperty(document, ‘getElementsByClassName’, {
	value: () => [{ clientHeight: 10 }],
});

4. globals [object] (Default: {})

• A set of global variables that need to be available in all the test environments.
• The globals object must be JSON-serializable, so it cannot be used to specify global functions. For that we use setupFiles.
• Example:

“globals”: [“__DEV__”: true],

5. collectCoverage [Boolean] (Default: false)

• As the name suggests, the function will collect coverage information while running test cases, if set to true.
• Considering code coverage to be the parameter of efficiency of unit testing, it should remain true in almost all environments – both Dev and Prod.
• This value can be kept negative when the developer is writing test cases and doesn’t want to run code coverage as it will significantly slow down the test cases.

6. collectCoverageFrom [Array] (Default: undefined)

• An array of glob patterns indicating a set of files for which coverage should be collected.
• Useful to define the folders which you want to include and exclude for the coverage.
• Useful for partial releases and also to have accurate numbers of Code Coverage, even for a subset of a code.
• Example:

“collectCoverageFrom”: [ ‘public/**/*.{js,jsx}’ ]

7. coverageThreshold [Object] (Default: undefined)

• This attribute specifies the minimum threshold enforcement for the coverage. If the thresholds are not met, then the test will fail.
• It can be assigned using glob pattern for any directory, file or path.
• Thresholds are assigned using numbers which represent minimum number required.
• Very useful in the production environment where the pre-decided coverage should be followed and also the quality of the delivery.
• Example:

“coverageThreshold”: {
	“global”: {
		“branches”: 90,
		“functions”: 80,
		“lines”: 80,
		“statements”: 80
	}
}

8. testPathIgnorePatterns [Array] (Default: [“/node_modules/”])

• An array of regex pattern strings that are matched against all test paths before executing the test. If the test path matches any of the patterns, it will be skipped.
• Use the string token to include the path to your project’s root directory to prevent it from accidentally ignoring all your files in different environments that may have different root directories.
• Example:

“testPathIgnorePatterns”: [
	‘<rootDir>/build/’, ‘<rootDir>/node_modules/’,       	‘<rootDir>/docs/’, ‘<rootDir>/gulpTasks/’
]

9. automock [Boolean] (Default: false)

• This option tells Jest that all imported modules in your tests should be mocked automatically.
• Automocking has a performance cost most noticeable in large projects, if set to true.
• All modules used in your tests will have a replacement implementation.

How Celestial implements JEST

Above are the major configurations that need to be set differently for Dev and Prod unit testing. In Celestial, we implement JEST along with Gulp using Gulp-Jest as we can configure JEST differently for different environments.

Other set of configurations can be found here: JEST-Configuration.

All the configurational options can also be used with the JEST-CLI with some cool hacks.