Gathering detailed insights and metrics for @salesforce/lwc-jest
Gathering detailed insights and metrics for @salesforce/lwc-jest
Gathering detailed insights and metrics for @salesforce/lwc-jest
Gathering detailed insights and metrics for @salesforce/lwc-jest
npm install @salesforce/lwc-jest
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
166 Stars
245 Commits
82 Forks
28 Watching
21 Branches
63 Contributors
Updated on 27 Nov 2024
Minified
Minified + Gzipped
JavaScript (79.67%)
HTML (19.69%)
Shell (0.64%)
Cumulative downloads
Total Downloads
Last day
-44.9%
54
Compared to previous day
Last week
-15%
403
Compared to previous week
Last month
-25.9%
2,075
Compared to previous month
Last year
-6%
30,113
Compared to previous year
Run Jest against Lightning web components in a Salesforce DX workspace environment.
To test against the latest Salesforce production instances, use the npm tag appropriate for the current release, e.g.:
yarn add -D @salesforce/sfdx-lwc-jest@winter22
yarn add -D @salesforce/sfdx-lwc-jest@spring22
The npm latest
tag corresponds to the latest version of this repo, not necessarily Salesforce production versions.
To see a full list of available versions, and the tag that maps to the corresponding Salesforce release, see the list of npm
package versions.
Add this project as a devDependency:
1yarn add -D @salesforce/sfdx-lwc-jest
Update your project's unit testing script in package.json
to execute sfdx-lwc-jest
:
1{ 2 "scripts": { 3 "test:unit": "sfdx-lwc-jest", 4 "test:unit:watch": "sfdx-lwc-jest --watch", 5 "test:unit:debug": "sfdx-lwc-jest --debug", 6 "test:unit:coverage": "sfdx-lwc-jest --coverage" 7 } 8}
test:unit
runs all your tests. test:unit:watch
and test:unit:debug
run Jest in watch and debug mode (see below).
Alternatively, you can globally install the package and run directly from the command line.
`sfdx-lwc-jest [options]` runs Jest unit tests in SFDX workspace
Options:
--version Show version number [boolean]
--coverage Collect coverage and display in output
[boolean] [default: false]
-u, --updateSnapshot Re-record every snapshot that fails during a test
run [boolean] [default: false]
--verbose Display individual test results with the test suite
hierarchy [boolean] [default: false]
--watch Watch files for changes and rerun tests related to
changed files [boolean] [default: false]
--debug Run tests in debug mode
(https://jestjs.io/docs/en/troubleshooting)
[boolean] [default: false]
--help Show help [boolean]
Examples:
sfdx-lwc-jest --coverage Collect coverage and display in output
sfdx-lwc-jest -- --json All params after `--` are directly passed to Jest
To pass any additional Jest CLI options to your run, pass them after the --
flag. All CLI parameters after the flag are passed directly to Jest.
1sfdx-lwc-jest -- --json
See the Jest documentation for all CLI options.
Debug mode lets you easily debug your Jest tests.
debugger;
into your codechrome://inspect
sfdx-lwc-jest
with the --debug
flag.Pass other parameters to Jest after the --
flag. For example,
1sfdx-lwc-jest --debug -- --no-cache
If you prefer to debug inside Visual Studio Code, follow these steps:
launch.json
with the following. (for Windows users see the Jest website for launch.json contents).1{ 2 "version": "0.2.0", 3 "configurations": [ 4 { 5 "name": "Debug Jest Tests", 6 "type": "node", 7 "request": "launch", 8 "runtimeArgs": [ 9 "--inspect-brk", 10 "${workspaceRoot}/node_modules/.bin/jest", 11 "--runInBand" 12 ], 13 "console": "integratedTerminal", 14 "internalConsoleOptions": "neverOpen", 15 "port": 9229 16 } 17 ] 18}
jest.config.js
file to the root of the Salesforce DX project as described here. You must add this file to run Jest from Visual Studio Code.Watch mode causes Jest to monitor files for changes and rerun tests related to the changed files. This is a great way to rapidly make component and test changes while monitoring tests results.
sfdx-lwc-jest
sets up all the necessary Jest configs for you to run tests out of the box without any additional changes. To override any options or set additional ones, create a file called jest.config.js
at the root of your Salesforce DX project, import the default config from sfdx-lwc-jest
, modify as you please, and then export the new config.
1const { jestConfig } = require('@salesforce/sfdx-lwc-jest/config'); 2module.exports = { 3 ...jestConfig, 4 // add any custom configurations here 5};
If a Lightning web component isn't located in the local lwc
directory of your Salesforce DX project, you must mock it in your Jest tests. This package includes a set of stubs for all components in the lightning
namespace.
This package installs stubs for the lightning
base components to the src/lightning-stubs
directory. These stubs are used automatically when running tests through sfdx-lwc-jest
. To override the default stub provided for your project, override the moduleNameMapper
config as described in Other Component Mocks.
For components from other namespaces, not in your local lwc
directory, create your own mock and update the Jest config to map the name of these components to the mock file.
Let's go through an example. We want to test the following template, helloWorld.html
.
1<template> 2 Hello From a Lightning Web Component! 3 <lightning-button onclick="{doSomething}"></lightning-button> 4 <foo-fancy-button onclick="{doSomethingElse}"></foo-fancy-button> 5</template>
Because it's in the lightning
namespace, the lightning-button
just works. However, you must write some code to help the Jest resolver find the foo-fancy-button
component. First, create a jest.config.js
file at the root of the Salesforce DX project workspace and add the following:
1const { jestConfig } = require('@salesforce/sfdx-lwc-jest/config'); 2module.exports = { 3 ...jestConfig, 4 moduleNameMapper: { 5 '^foo/fancyButton$': '<rootDir>/force-app/test/jest-mocks/foo/fancyButton', 6 }, 7};
This config tells Jest to map the import for foo-fancy-button
to the provided file. Notice that the first dash is converted to a forward slash and the rest of the component name goes from kebab to camel case. The reason for the forward slash is because the module resolver treats everything before the first dash as the namespace. Here, <rootDir>
maps to the root of the Salesforce DX workspace. Note that this file location is not required, just an example.
You also have the freedom to make these mock implementations as sophisticated or simple as you'd like. In this example, we'll keep foo-fancy-button
simple with an empty template and no functionality in the .js
file, but you can always add whatever markup you'd like or implement functionality like any other Lightning web component.
Finally, we need to create the mock foo-fancy-button
files. In the force-app/test/jest-mocks/foo
directory create the following files:
1<!-- fancyButton.html --> 2<template></template>
1// fancyButton.js 2import { LightningElement, api } from 'lwc'; 3export default class FancyButton extends LightningElement { 4 @api label; 5 // any other implementation you may want to expose here 6}
To provision data through @wire
adapters in unit tests, use the APIs provided by @salesforce/wire-service-jest-util
. These APIs are exposed through this package so you do not need to include another dependency in your package.json.
See the @salesforce/wire-service-jest-util
README for further documentation on these APIs.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
13 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
0 existing vulnerabilities detected
Reason
security policy file detected
Details
Reason
Found 16/20 approved changesets -- score normalized to 8
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More