To verify the functionality of your Apex code, Gearset allows you to run your Salesforce unit tests when you deploy changes to your orgs. There are four different test levels you can choose from.
Apex test levels
Below options represent different behaviors of apex test levels.
Salesforce default tests
In a sandbox: No tests are executed.
In production: All local tests are executed if your deployment package contains Apex classes, triggers, or Flows (set to be active upon deployment).
Local tests include all tests except those from managed packages.
If your deployment package does not contain Apex classes, triggers or Flows (flows which are set to be active upon deployment), then no tests are run.
Note: When deploying to Production, not only must your org meet the 75% overall Apex code coverage requirement, but all executed tests must pass. If any test fails, the deployment will fail — even if code coverage is above 75%.
RunRelevantTests (API version 66+)
Salesforce introduced RunRelevantTests (Beta) in Spring ’26 (API 66). This option dynamically selects which Apex tests to run based on the components included in a deployment. Read more about this option here.
Don't run any tests
No tests are executed unless:
You are deploying to production, and
Your package contains Apex classes, triggers, or Flows set to be active upon deployment.
In this case, Salesforce default tests will be executed.
Run only your tests
All tests in your organization are run, except those that originate from managed packages.
Specify tests to run
Only the tests that you specify are run. You must specify names of test classes in a comma-separated list. Code coverage requirements differ from the default coverage requirements when using this level in production. The executed tests must cover the classes or triggers in your deployment package with a minimum of 75% code coverage. This coverage is computed for each class or trigger individually and is different from the overall coverage percentage. The pre-populated apex tests are either in the deployment package or have dependencies in the package.
Note: UI tests will be triggered after a successful deployment. The results will not be shown in Gearset, you'll need to check your provider for details.
Specifying the test level in Gearset
Manual compare and deploy
Validations: To run the default test level, click the main
Validate deploymentbutton 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 Nowbutton 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.
Continuous integration
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 & Test Suites: Define a manual list of individual test classes or test suites to run. Each test class or suite name should be separated by a comma.
Tests that reference Apex changes: instruct Gearset to run tests that have a compile-time reference to Apex changes included in each CI job run's package. If you change or add new Apex tests in your package, those will also be included.
Tests that match naming conventions: instruct Gearset to run tests that match naming conventions of Apex changes included in each CI job run's package.
Tests that are in the deployment: instruct Gearset to run all the Apex test classes that are included in the deployment package.
To understand more about the latter two options, here's an article explaining how Gearset selects which tests to run.
RunRelevantTests behavior in CI jobs
RunRelevantTests (API version 66+): Salesforce introduced RunRelevantTests (Beta) in Spring ’26 (API 66). This option dynamically selects which Apex tests to run based on the components included in a deployment.
While this is conceptually similar to our Suggested tests functionality, test selection is handled entirely by Salesforce rather than Gearset. When RunRelevantTests is enabled, Salesforce determines which tests are executed during deployment. Because test selection is handled by Salesforce, additional tests specified on individual pull requests in Gearset will not be included.
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.
RunRelevantTests relies on Salesforce’s internal dependency analysis and may require code annotations or structural changes to test classes to influence which tests are executed.
RunRelevantTests test selection behavior
Based on testing with Salesforce API version 66, there are a few behaviors teams should be aware of:
• 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 Salesforce’s dynamically selected tests.
• The @isTest annotation continues to behave at the class level, meaning all test methods in that class are executed when the class is selected.
• Dependency layering can affect which tests are selected. This is similar to how intermediate classes can influence test selection in other dependency-based strategies.
We are adding support for RunRelevantTests in CI jobs. Manual deployments will be supported later.
⚠️ RunRelevantTests is only supported on API version 66 or higher⚠️
If a CI job is configured to use RunRelevantTests but executes at API version 65 or below, Gearset will throw an error and the run will fail.
Why Gearset errors instead of falling back
If RunRelevantTests is selected but the deployment runs at API version 65 or lower, we return an error rather than falling back to another test level.
This is intentional:
Falling back to
RunLocalTestscan significantly increase validation and deployment times, delaying feedback and blocking PR merges.Falling back to
RunSpecifiedTestsrisks running a different set of tests than expected, which could allow issues to slip through and introduce bugs into your org.
Failing fast ensures deployments behave predictably and prevents unintended test execution.
Resolution
To fix this, ensure your deployment runs on API version 66 or later:
Update your metadata filter to use API version 66+ (or Highest common version), or
Update your VCS API version to 66+
A note on the formatting of test classes for managed packages
If you're needing to run test classes out of a managed package, as part of the deployment of some unmanaged code, you'll need to specify them as "namespacehere.ClassNameHere". Using a period rather than an underscore. This is verified as per this Salesforce documentation.
For more information on Apex unit tests, see this Salesforce Trailhead module on testing: https://trailhead.salesforce.com/en/modules/apex_testing/units/apex_testing_intro