---
schema_version: "1"
id: a545077cd34425b94d16954b8513bca77f7b7bbd7649eb2f4b541b0a24728026
title: Test Your Plugin
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/salesforcedx/sfcliplugin/guides/test-plugin.md
canonical_url: https://developer.salesforce.com/docs/platform/salesforce-cli-plugin/guide/test-plugin.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: c9277ca477b4ad18dfe7ef6cc81b9f328af93ba7aa2b589566705b5189bed98d
products:
  - Salesforce CLI Plugin Developer Guide
  - salesforcedx
---
# Test Your Plugin

It's critical to test your plugin to make sure it works correctly, safely, and in a consistent way.

## Our Testing Philosophy

We (the Salesforce CLI dev team) use two types of tests to fortify the quality of our plugins:

- [Unit tests](#unit-tests)
- [Non-unit-tests (NUTs)](#non-unit-tests)

We use unit tests to test library-level code and NUTs to test command-level code. With this philosophy, unit tests verify the functionality of the classes and functions consumed by a command. And then NUTs verify that the command itself works as expected.

You can, of course, test your plugin however you want, although we recommend you give our philosophy a try. The next 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 [mocha](https://www.npmjs.com/package/nyc) to run the tests and [nyc](https://www.npmjs.com/package/nyc) for test coverage. You're not limited to this framework - you're welcome to use whatever NodeJS-compatible testing framework works best for you, such as [jest](https://jestjs.io/).

Here are some examples of how we use unit tests across our codebases:

- [Custom flags in @salesforce/plugin-deploy-retrieve](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/main/test/utils/flags.test.ts)
- [Various utility functions in @salesforce/plugin-deploy-retrieve](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/main/test/utils/deploy.test.ts)
- [`env list` hook in @salesforce/plugin-env](https://github.com/salesforcecli/plugin-env/blob/main/test/hooks/envList.test.ts)
- [Time utilities in @salesforce/plugin-env](https://github.com/salesforcecli/plugin-env/blob/main/test/utils/timeUtils.test.ts)
- [`AuthInfo` tests in @salesforce/core](https://github.com/forcedotcom/sfdx-core/blob/main/test/unit/authInfoTest.ts)

### Unit Tests for Commands

While we **strongly** recommend writing [NUTs](https://developer.salesforce.com/docs/platform/salesforce-cli-plugin/guide/test-plugin.md#non-unit-tests) for command-level unit tests, it's possible to do this. Here's a brief example:

```typescript
import { expect } from "chai";
import { TestContext } from "@salesforce/core/lib/testSetup";
import { stubSfCommandUx } from "@salesforce/sf-plugins-core";
import { DoStuff } from "../../../../src/commands/do/stuff";

describe("do:stuff", () => {
  const $$ = new TestContext();
  let sfCommandUxStubs: ReturnType<typeof stubSfCommandUx>;

  beforeEach(async () => {
    // stub SfCommand's ux methods so that command output is suppressed
    // and so that you can assert that certain methods were called with
    // the correct args.
    sfCommandUxStubs = stubSfCommandUx($$.SANDBOX);
  });

  it("should do awesome things", async () => {
    // run the command using the static run method
    const result = await DoStuff.run(["--flag1", "--flag2"]);

    expect(result).to.be.ok;
    expect(sfCommandUxStubs.log.firstCall.firstArg).to.equal("hello world");
  });
});
```

Here are some examples of how we write command-level unit tests across our codebases:

- [`org:display` unit tests](https://github.com/salesforcecli/plugin-org/blob/main/test/unit/org/display.test.ts)
- [`org:list` unit tests](https://github.com/salesforcecli/plugin-org/blob/main/test/unit/org/list.test.ts)

See the [stubUx docs](https://salesforcecli.github.io/sf-plugins-core/modules/stubUx.html) for built-in stubs for spinners, tables, warnings, prompts, and more.

## Non-Unit-Tests

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're not required to write and maintain mocked API responses anymore.

See the examples in the [@salesforce/cli-plugins-testkit repo](https://github.com/salesforcecli/cli-plugins-testkit).