Test Your Plugin

Our Testing Philosophy

We use two types of tests to ensure the quality of our plugins:

1. Unit tests
2. Non-unit-tests (NUTs)

We generally use unit tests to test library-level code and NUTs to test command-level code. For example, unit tests ensure the functionality of the classes and functions consumed by a command, and then NUTs ensure that the command itself works as expected.

Non-Unit-Tests (NUTs)

We use non-unit-tests, known as NUTs, for command-level testing. NUTs include integration tests, functional tests, UI tests, smoke tests, and more. They typically require any system outside your code to accomplish the test.

This style of testing allows you to use an isolated Salesforce project and file system against production Salesforce instances. Because of this, you're able to write tests that mimic customer's environments as closely as possible. It also means that you don't have to write and maintain mocked API responses anymore!

You can see a list of our examples in the @salesforce/cli-plugins-testkit repo.

Unit Tests

For library level code we like to write unit tests using the nyc/mocha framework. You, however, are not limited to this framework - you are free to use whatever NodeJS compatible testing framework (e.g. jest).

Here are a few examples of how we leverage unit tests across our codebases:

• custom flags in @salesforce/plugin-deploy-retrieve
• various utility functions in @salesforce/plugin-deploy-retrieve
• env list hook in @salesforce/plugin-env
• time utilities in @salesforce/plugin-env
• AuthInfo tests in @salesforce/core