How To Use Coverage and Test Reporters With LWC Jest | by Sebastiano Vierk | May, 2022

Generate test results and code coverage reports for Lightning web components

Photo by Felix Mittermeier on Unsplash

Jest is a JavaScript testing framework that works with different types of projects including Angular, React as well as Salesforce Lightning Web Components. Even though in the Salesforce ecosystem, LWC unit tests and their coverage are not relevant for deployments in contrast to Apex code coverage, in my opinion, good tests with high coverage are also important here to ensure high code quality in the UI.

There are already a number of well-written guides about Jest testing for Lightning Web Components in general. Therefore, I would like to focus on the test result and coverage reporting part of this guide.

Before we start, here’s some sample HTML code coverage from Lightning:

Sample LCOV HTML Code Coverage Report for Lightning Web Components
Sample LCOV HTML code coverage report for Lightning web components

All right, let’s jump right into it.

When creating a new SFDX project, the default Jest configuration for LWC unit tests is located in the project root directory and looks like this:

If you leave this configuration unchanged, you can use the following command to calculate the corresponding code coverage for the currently existing LWC test classes:

sfdx-lwc-jest --coverage

If sfdx-lwc-jest is not installed globally, but only as a dependency of your current project, you can also add corresponding scripts in the package.json file like this:

Scripts for LWC test execution in package.json
Scripts for LWC test execution in package.json

These scripts can then be executed. For example, as follows:

npm run test:unit:coverage

After running the command and finishing the execution of all tests, the calculated code coverage is output in the terminal:

Terminal Output for LWC Code Coverage
Terminal Output for LWC Code Coverage

Additionally, an LCOV coverage report is automatically generated in the /coverage directory of the project. However, in some projects, you may need code coverage and test results generated in other formats, such as with Cobertura or JUnit, to be able to use them for reporting or publishing in an automated pipeline run.

So, in the next section, we will look at how to extend the default configuration of LWC Jest for an SFDX project.

In the previous section, we saw what is possible with the provided LWC Jest default configuration. However, referring to the official documentation, it is possible to override or extend the configuration with various options (Configuring Jest). If you do this, you can also use the previously mentioned reporters.

For example, to make use of Cobertura or other coverage reporters and formats you just need to add the following line to the existing jest.config.js configuration file:

coverageReporters: ['clover', 'json', 'text', 'lcov', 'cobertura'],

If the configuration is extended in this way, this automatically leads to the additional output of the specified report types in the /coverage directory.

To have JUnit support enabled as well you need an additional npm package called jest-junit that can be installed as a dev dependency of your project as follows:

npm i jest-junit --save-dev

To then automatically use this reporter with Jest, it must also be added to the jest.config.js configuration file. The final Jest configuration with all the adjustments would then look like this:

From now on, the following two directories will be automatically filled with our test reports for each test execution. The /coverage directory contains all the code coverage-related information and the /tests directory contains all the general results for the latest test execution.

Generated directories with the results of the latest LWC test execution
Generated directories with the results of the latest LWC test execution

Previously, we saw how to generate test results and code coverage reports in various formats for Lightning Web Components. Now there are several uses for them. For example, the configuration shown above can be used in CI/CD pipelines to publish code coverage information to code analysis tools like SonarCloud or to even make test results visible directly in a pipeline run. Let’s take a look at how the latter works, using Azure Pipelines as an example.

Example usage with Azure pipelines

Azure Pipelines is the CI/CD automation solution within Microsoft’s Azure DevOps Tool Suite and can be used to build, test and deploy your code. Of course, this is not meant to be a guide to Azure Pipelines, however, let’s just take a look at how we could add corresponding tasks for the LWC test execution and result in reporting as an example.

Let’s just assume we have a CI pipeline that is automatically executed on a pull request and we would like to see for each pipeline run the corresponding test results as well as the computed code coverage.

First, we need to run our tests to generate our reports, as we did before locally. The design of the pipelines is defined in YAML format. To our YAML pipeline definition file, we can add the following task for the execution of the LWC tests, which again uses the previously defined script from our package.json.

This task executes all tests and does not abort even if some tests fail, since we are of course interested in all possibly failed tests at the end.

JUnit test report in Azure pipelines

To publish the overall results of our current test execution, we just need to add another task to our pipeline definition file. This task automatically searches for the specified results file and publishes it for the current pipeline run.

The next time we run the pipeline, we will see a new “Tests” tab where based on our generated test report, the results will be displayed nicely formatted as follows:

Sample JUnit Test Report in Azure Pipelines
Sample JUnit Test Report in Azure Pipelines

Cobertura code coverage report in Azure pipelines

In addition to the general results of our tests, we are of course also interested in their respective code coverage. There is a corresponding task in Azure Pipelines for this as well, which we can add to our pipeline definition. This task also receives the specification of the format as well as the corresponding path to the resulting file:

After the next pipeline execution, this task also creates a new tab labeled “Coverage,” which also nicely formats the respective code coverage of our LWC tests for the current run.

Sample Cobertura Code Coverage Report in Azure Pipelines
Sample Cobertura Code Coverage Report in Azure Pipelines

In this guide, we have looked at how LWC Jest can be used to generate different types of test results, code coverage reports, and how they can be used in CI/CD processes. Of course, this does not only apply to Azure Pipelines as shown here but also to other pipeline solutions such as Bitbucket Pipelines, GitHub Actions, or GitLab CI/CD.

In one of my repositories on GitHub, the test configuration shown in this guide is also available again as a reference, as well as its use in GitHub Actions, which include the automated publishing of test results in a personal SonarCloud project.

Leave a Comment