Gearset can run your Salesforce unit tests when you deploy changes to your orgs, so you can verify your Apex code before it reaches the target org. Use this article to pick a test level and set it for a manual deployment or a CI job.

What are the Apex test levels?

Gearset runs a different set of Apex tests at each test level. The following table shows which tests each level runs, and the code coverage each level requires.

Test level	Which tests run	Coverage requirement
`Salesforce default tests`	In a sandbox, none. In production, all local tests run if your deployment package contains Apex classes, triggers, or Flows set to activate on deployment. Local tests exclude tests from managed packages. If your package contains none of those, no tests run.	In production, 75% overall Apex code coverage, and every test that runs must pass. A single failed test fails the deployment, even at above 75% coverage.
`Relevant Tests`	Salesforce selects the tests, based on the components in the deployment. See "How does `Relevant Tests` behave in CI jobs?" below.	75% overall Apex code coverage
`All your tests`	Every test in your org. Including tests from Managed Packages.	75% overall Apex code coverage
`Don't run any tests`	None, unless you deploy to production and your package contains Apex classes, triggers, or Flows set to activate on deployment. In that case, Salesforce default tests run instead.	75% overall Apex code coverage
Specify tests to run `Choose Tests To Run`	Only the test classes you name.	Each class or trigger in your deployment package needs at least 75% coverage on its own. This is computed per class or trigger, and differs from the overall coverage percentage.

Specify tests to run

When you pick "Specify tests to run", name the test classes yourself:

Enter the test class names in a comma-separated list.
Gearset pre-populates the tests that are in the deployment package, or that have dependencies in the package.

Note: UI tests are triggered after a successful deployment. Gearset does not show the results, so check your provider for details.

How do I set the test level in Gearset?

You set the Apex test level in two places depending on what feature you are using:

Manual compare and deploy

Validations: To run the default test level, click the main Validate deployment button on the pre-deployment summary. To specify the other test levels, click the arrow to the right of the button and choose the test level for the validation.

Deployments: To run the default test level, click the main Deploy Now button on the pre-deployment summary. To specify the other test levels, click the arrow to the right of the button and choose the test level for the deployment.

Continuous integration and Pipelines

You can set the test level when creating or editing a CI job in the Test settings tab. If you make changes to the test level of an existing job, they will be applied the next time the job runs.

When selecting the option For more control, a few more granular options will appear. This will enable you to maximize the chances of running all the relevant tests and achieving acceptable code coverage.

Test classes and test suites: Define a manual list of individual test classes or test suites to run. Separate each test class or suite name with a comma.
Tests that reference Apex changes: Run tests that have a compile-time reference to the Apex changes in each CI job run's package. Apex tests you change or add in the package are included too.
Tests that match naming conventions: Run tests whose names match the naming conventions of the Apex changes in each CI job run's package.
Tests that are in the deployment: Run every Apex test class included in the deployment package.

For more on the last two options, see Gearset suggested Apex tests.

How does `Relevant Tests` behave in CI jobs?

Relevant Tests is a Salesforce test level, so Salesforce decides which Apex tests run during a deployment, not Gearset. That has three consequences for a CI job:

Additional tests specified on individual pull requests in Gearset are not included.
You cannot adjust test selection on a pull request. Gearset's Suggested tests lets teams add or adjust tests on a pull request without changing their codebase. Relevant Tests does not.
Influencing which tests run may need code annotations or structural changes to your test classes, because Salesforce uses its own internal dependency analysis.

One key difference from our Suggested tests logic is that Suggested tests allow teams to add or adjust tests directly on pull requests without modifying their codebase.

Relevant Tests test selection behavior

Testing against Salesforce API version 66 showed these Relevant Tests behaviors:

Apex classes must use API version 66 or later in their *-meta.xml files for test annotations to take effect.
The @isCritical annotation is always included in the tests Salesforce selects.
The @isTest annotation still behaves at class level, so every test method in a class runs when that class is selected.
Dependency layering can affect which tests are selected, in the same way intermediate classes can influence test selection in other dependency-based strategies.

Note: Relevant Tests needs Salesforce API version 66 or later. If a CI job is set to use Relevant Tests but runs at API version 65 or lower, Gearset returns an error and the run fails.

Why Gearset returns an error instead of falling back

If you select Relevant Tests but the deployment runs at Salesforce API version 65 or lower, Gearset returns an error instead of falling back to another test level. This is intentional:

Falling back to RunLocalTests can significantly increase validation and deployment times, which delays feedback and blocks pull request merges.
Falling back to RunSpecifiedTests risks running a different set of tests than expected, which could let issues slip through into your org.

Failing fast keeps deployments predictable and prevents unintended test execution.

How do I fix the API version error?

To fix the error, run the deployment on Salesforce API version 66 or later. Update either of these:

Your metadata filter to API version 66 or later, or to Highest common version.
Your VCS API version to 66 or later. Ensure you read this article before carrying the change out.

How do I format test class names for managed packages?

To run test classes from a managed package as part of a deployment of unmanaged code, specify each one as namespacehere.ClassNameHere. Use a period, not an underscore. Salesforce's deployment documentation confirms that a class name can include a namespace in dot notation.

For more on Apex unit tests, see Salesforce's Apex testing Trailhead module.

Setting Apex test levels