Jest Configuration And Debugging Jest Based Tests

By Vijay

By Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.
Updated March 7, 2024

Learn about Jest Config, Debugging and comparing Jest with other JavaScript testing frameworks specifically Jest vs Mocha & Jest vs Jasmine:

In this Informative Jest Series, we explored all about Testing React Apps, Mocks and Spies using Jest in our last tutorial.

In this tutorial, we will learn more about Jest Config files and see how you can actually debug Jest tests for troubleshooting one or more multiple tests.

We will also explore some of the commonly used options in the Jest Config file that could be set up independently in a project or those that can be added as a part of the package.json configuration itself.

Jest Config and Debugging

We will be using Visual Studio Code for writing our Jest tests and would use an extension or plugin in VS Code to enable debugging support for Jest tests.

In addition, we will compare the different Javascript testing frameworks like Mocha and Jasmine with Jest and understand the pros and cons of each other.

Jest Config

Jest configuration can be specified in 3 ways

  • Through a key in package.json file.
  • Through a jest.config.js file – Configuration file written as a module.
  • Through a JSON that could be used with the option as –config flag.

With all the above approaches, you can achieve the same outcome. Let’s see the first step – i.e. adding Jest configuration through a key in package.json file.

In the existing package.json file, add a new key named “jest”. This is nothing but a set of key-value pairs in JSON format. All the configuration options related to Jest can be further added to this section in the package.json file.

add config options

The most frequently used configuration options are listed below.

#1) Coverage Related

collectCoverage, coverageThreshold, coverageReporters, coverageDirectory – These are the most widely used options. Coverage is an important metric and it ensures that the code is tested against a preset threshold.

A detailed explanation of each of them is as follows:

#1) collectCoverage: This option is used to specify if we want the Jest test runner to collectCoverage information or not. When set to true, the Jest runner collects the coverage information. With this option, the coverage will be collected and displayed on the console at the end of the test execution as shown below.

#2) coverageThreshold: This setting allows us to specify the threshold values for coverage in percentage terms. This is greatly helpful when the organization or team wants to adhere to a certain minimum value of coverage without which no code can be pushed or merged to the main branch.

Let’s see how this can be used.

Coverage can be specified at the global level, file-level, or any other regex. When specified at the global level, all the specified threshold should match for the combined all the files in the project.

"coverageThreshold": {
     "global": {
       "branches":95,
       "functions":100,
       "lines":70,
       "statements":-2
     }
}

Specifying coverage at the file level is also possible, by changing “global” to filename or regex. The threshold configurations can vary depending on the requirement.

"coverageThreshold": {
"./src/calculator.js": {
       "branches":100,
       "functions":100,
       "lines":100,
       "statements":-10
    }
}

#3) coverageReporters: This config is used to specify what reporter you would like to use in order to generate the coverage report. There are a lot of existing reporters as NPM packages available that could be used to generate a coverage report at the end of test execution.

#4) coverageDirectory: This setting allows the user to specify the directory where the coverage reports should be saved or persisted after being created.

Given below is a combined example of using all the coverage related config settings.

 "jest":{
   "collectCoverage":true,
   "coverageThreshold": {
     "global": {
       "branches":95,
       "functions":100,
       "lines":70,
       "statements":-2
     },
     "./src/calculator.js": {
       "branches":100,
       "functions":100,
       "lines":100,
       "statements":-10
     }
 
   },
   "coverageReporters": [
     "lcov","text"
   ],
   "coverageDirectory": "./output/code-coverage/"
   }

Here, we have used 2 coverage reporters i.e. lcov and text.Lcov is Linux’s line coverage and is present by default and the“text” reporter means that the coverage output will also be displayed on the console. The coverage report will be generated at the path specified in the “coverageDirectory” setting.

jest-coverage directory

#2) Mock Related 

Mocks are heavily used while testing with Jest. Both the below configuration options allow easy configuration and clearing up of mocks.

  • autoMocks: When set to true, this will mock all the modules that are imported in the test by default.
  • clearMocks: When set to true, this will clear all the mocked setup/modules after each test, so that every test starts with a fresh state. This can also be achieved using the testCleanup or the “after” method, but having it in config makes it even easier.

#3) Tests Related

#1) testTimeout: This config is used to provide a hard timeout setting for tests in milliseconds. Any test taking more than this configured threshold will be marked failed due to timeout exception.

"jest" {
"testTimeout": 100
}

#2) Globals: This config is used to set global variables that should be available with each test.

"jest" {
"globals": {
     "globalVar": "test global variable!"
   }
}

Let’s try using a global variable in the test and see if it works as expected.

describe("Calculator tests", () => {
   test("add 2 numbers", () => {
       // arrange & act
       const val = mathOps.sum(3,4)
       console.log(globalVar)
      
       // assert
       expect(val).toBe(7)
   })

After executing this test, the value of globalVar should be logged.

jest_output

Check here for the exhaustive list of all configuration options.

Video Tutorial On JEST Configuration

Debugging Using Jest

In this section, we will try to understand how we can debug tests written based on Jest.

We will apply and understand 2 different ways in which we can debug Jest tests.

  1. Node’s native debugger and then using Chrome Inspector to debug the tests.
  2. Using Visual Studio Code’s debug configuration to debug the tests within the Visual Studio Code editor itself. This is the most commonly used way to debug as Visual Studio Code is the default editor of choice for most of the Javascript development these days.

Each of these approaches is explained below in detail.

#1) Using Node’s Native Debugger

In order to use Node JS native debugger, we need to insert the ‘debugger’ keyword in the test, where we want to place the breakpoint.

Once the test executor encounters the debugger command, it pauses the execution and if we attach chrome debugger tools, then we can debug the test code (as well as the function under test) using Chrome tools.

Chrome browser is a prerequisite here in order to use Node’s Native Debugger.

Please follow the below steps.

#1) Add debugger keyword within the test i.e at the point where you would like the test to hit the breakpoint, insert the “debugger” command

#2) Execute the test using –inspect-brk flag.

Use the below command to execute the test in a breakpoint mode.

/usr/local/bin/node --inspect-brk ./node_modules/jest/bin/jest.js --runInBand

#3) Attach the Node’s debugger in Chrome. Now in the Chrome browser, navigate to chrome://inspect and connect to the target listener that’s created by the above step.

Node's debugger in Chrome

#4) Continue the execution, and you will see that the breakpoint hits in the chrome debugger inspector and you can debug the call stack and object state in the chrome debugger itself.

chrome_debugger

This approach of debugging Jest tests is okay but not very user friendly as you need to keep switching from the code editor to Chrome and vice versa that causes a lot of friction. In the upcoming section, we will see the ways of configuring the debugger within the Visual Studio Code editor itself.

#2) Using VS Code’s Debug Configuration

#1) Select the Debug / Run section of the Visual Studio Code from the left panel.

Run/Debug

#2) Now, we will update the debug configuration for jest tests. To do that add a new configuration by selecting the menu option.

select add configuration

#3) Once the add configuration option is selected, it will open the `launch.json` file with the default content in the editor pane. Remove the default content and copy the content below for creating a debug configuration for the Jest tests.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Jest Tests",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "--inspect-brk",
        "${workspaceRoot}/node_modules/jest/bin/jest.js",
        "--runInBand"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "port": 9229
    }
  ]
}

#4) Save the newly added content configuration that would be used to debug the Jest tests. If you read through the config carefully, it’s similar to what we did when we tried to connect to the Node debugger in the Chrome Developer tools through the command.

--inspect-brk ./node_modules/jest/bin/jest.js --runInBand

The advantage of having config here is that the tests will run/debugged as a part of the Editor itself (in this case it’s VSCode) and we don’t need to connect to any external application.

#5) Once the debug configuration is created, you can now add breakpoints to the tests and execute using this RUN configuration. This will ensure that the test stops at the breakpoints and you can debug the values, object state at the breakpoint in the actual test file.

Breakpoints can be added by clicking near the line numbers in the code files.

Set Breakpoint

#6) Once the breakpoint is added, we can select the Run configuration that we added in the step#3 in order to execute/debug the test.

Select Run Configuration

#7) On selecting/clicking the Run button, you should be able to see that the execution hits the breakpoint that was placed and you can get more details like environment / variable values, stack trace, etc at the breakpoint.

The breakpoint/code flow control buttons can be used to move to the next breakpoint or move inside the function for more details.

breakpoint_execution_jest

Video Tutorial On JEST Debugging

Jest Vs Mocha Vs Jasmine

In the below section we will compare Jest vs Mocha and Jest vs Jasmine on different parameters and feature comparisons like Snapshot testing, Ease of configuration, and Capabilities of different frameworks.

ParameterJestMochaJasmine
Snapshot testingFully supported - Specifically used for React components, Jest supports taking snapshots of a component and using it to compare the test output against the saved component structure.
Snapshots are a great way to ensure that UI’s do not change unexpectedly.
No supportNo support
Assertions and MatchersUse expect.js library for matchers.Support for Node’s built in assert module, and can also include other assertion libraries.In built assertions
MockingFully built in support for Mocks and Stubs in Jest.No in built support for mocking or stubbing.
Can be used with other libraries like Sinon to support Mocking.
Inbuilt limited support using spyOn.
Can integrate with other libraries.
Speed of Execution4x
Jest tests are isolated in their own sandbox. Thus Jest tests are essentially running in parallel due to which they provide considerable improvement in execution times.
x
Does not support parallel execution of tests.
x
Does not support parallel execution of tests.
Configuration & SetupVery easy - zero configuration required.
Mode of test executionHeadlessHeadlessHeadless
Testing types supportedMostly used for unit testing.Unit testingUnit testing and E2E testing.
Test Output and ContextGenerates rich context post execution - Jest provides detailed test context to dig deep into what has caused a failure thereby ensuring easy debugging.Test output is not very readable and makes debugging a little challenging.
DebuggingSupport for native Node debuggers can also be used to debug within editors like Visual Studio Code through a separate launch configuration.Supports native Node debugger.Can use karma test runner to launch tests in Chrome and debug.
Code coverageJest has inbuilt support for code coverage.
Coverage configuration could be specified in Jest configuration and the reports could be generated with each test execution.
No inbuilt support. Provides support for external libraries to generate coverage reports.Same as Mocha
Style of testingBDD
All the three frameworks support tests to be written as a set of specs or specifications which make them more readable.
BDDBDD

Conclusion

In this tutorial, we learned about the different ways in which you can debug your Jest tests within Visual Studio Code, or in the Chrome Inspector using the Node’s native debugger.

We also explored the commonly used configuration options in the Jest config file. Jest configuration helps to achieve a lot of things like Code coverage, Html reports, Setting up mock behaviors, Setting up global variables, etc.

PREV Tutorial | FIRST Tutorial

Was this helpful?

Thanks for your feedback!

Leave a Comment