CLI tests use Jest to test Strapi CLI commands and functionality. They share the same infrastructure as e2e tests:

• Shared app template: Both test types use tests/app-template to generate test applications
• Shared utilities: Common test utilities are in tests/utils/
• Shared runners: Test app setup and management is handled by tests/utils/runners/shared-setup.js
• Unified test runner: Both use tests/scripts/run-tests.js with different execution strategies

The main difference is that CLI tests use Jest for test execution, while e2e tests use Playwright for browser automation.

Run yarn test:cli to begin. The command will generate the required number of test applications based on the shared app-template, seed them with preconfigured data [not yet implemented], then run the test suites (or "domains").

The -c X option can be used to limit the number of concurrently running domains, where X is the number to be run simultaneously.

If any changes are made to the template, or other issues are being encountered, try removing and regenerating the test apps by using yarn test:cli:clean before running the tests.

The coffee library is used to run commands and expect input, complete prompts, etc. Please see their documentation for more details.

Warning: Due to issues with the monorepo in regards to linking packages, we currently have to use 'npm' instead of 'yarn' to run internal CLI commands

When a test domain is run, the path to the available test app is provided in the comma-separated env variable TEST_APPS. The number of apps provided will be the number of testApps set in the configuration, or the default of 1.

For example, if 2 test apps are requested, you should receive an env such as: TEST_APPS=/test-apps/cli/test-app-0,/test-apps/cli/test-app-3

Your CLI commands being tested can then be run in that directory.

As the CLI generally does not require a running Strapi app, this is not managed by the CLI testing tool.

After tests for remote data-transfer are implemented, there will be utility functions available to assist in running one or more of the test apps in the background while other tests are run against it.

Each subdirectory within the ./tests directory here is considered a test "domain" and will have its own test app(s) available. By default only one test app is made available unless additional ones are configured in a config.js within that test domain.

This optional file should return a function that returns a configuration object like the following complete example:

module.exports = () => {
  return {
    testApps: 2, // the number of test apps to be made available
  };
};

See the available tests in the tests directory for examples.