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.
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.
Table of Contents:
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.
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.
#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.
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.
- Node’s native debugger and then using Chrome Inspector to debug the tests.
- 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.
#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.
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.
#2) Now, we will update the debug configuration for jest tests. To do that add a new configuration by selecting the menu option.
#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.
#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.
#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.
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.
Parameter | Jest | Mocha | Jasmine |
---|---|---|---|
Snapshot testing | Fully 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 support | No support |
Assertions and Matchers | Use expect.js library for matchers. | Support for Node’s built in assert module, and can also include other assertion libraries. | In built assertions |
Mocking | Fully 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 Execution | 4x 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 & Setup | Very easy - zero configuration required. | ||
Mode of test execution | Headless | Headless | Headless |
Testing types supported | Mostly used for unit testing. | Unit testing | Unit testing and E2E testing. |
Test Output and Context | Generates 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. | |
Debugging | Support 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 coverage | Jest 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 testing | BDD All the three frameworks support tests to be written as a set of specs or specifications which make them more readable. | BDD | BDD |
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