Test Your Plugin

Our Testing Philosophy

We (the Salesforce CLI dev team) 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.

You can of course test your plugin however you want. But we highly recommend you follow our philosophy. These sections describe in more detail how we use NUTs and unit tests.

Unit Tests

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

Here are some 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

Non-Unit-Tests (NUTs)

We use non-unit-tests, known as NUTs, for command-level testing. As the name implies, NUTs are automated tests that aren't unit tests. NUTs typically include integration, functional, UI, and smoke tests that require a 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 orgs. As a result, you can write tests that mimic your customers' environments as closely as possible. And you don't have to write and maintain mocked API responses anymore.

Check out the examples in the @salesforce/cli-plugins-testkit repo.