General Scenarios
In general, the RunLocalTests option is recommended to ensure there are no regressions. However, in many Salesforce orgs, running all local Apex tests can take hours, making this approach a potential bottleneck.
There isn’t a one-size-fits-all answer for the test level to enforce for each deployment, but here are some general recommendations:
- Test Level for INT/SIT/QA Deployments:
- Since these are the first environments in the pipeline and deployments are frequent, the priority is ensuring smooth and efficient deployments.
- NoTestRun or RunSpecifiedTests are typically suitable options.
- Note: If the total runtime of all Apex tests is less than 10 minutes (uncommon), RunLocalTests can also be considered.
- Test Level for UAT and Production Deployments:
- UAT deployments should mimic production deployments as closely as possible. For this reason, RunLocalTests is recommended, regardless of whether the metadata changes include Apex code.
- Even minor metadata changes (e.g., a validation rule) can cause bugs detectable by Apex tests. Ensuring these tests run helps safeguard production quality.
Edge Scenarios
In edge cases, such as Hotfix Deployments where a production deployment must be executed quickly, the primary consideration is whether the release contains Apex code changes. Keep in mind that for production deployments involving Apex code, a minimum coverage of 75% for the modified code is mandatory.
To determine if the release contains Apex code changes, refer to Inspect a Release
- If Apex Code Changes Are Included:
- To minimize test execution time, use RunSpecifiedTests and specify the test classes required to meet the necessary code coverage.
- If this is not feasible, you must use RunLocalTests to ensure adequate coverage.
- If No Apex Code Changes Are Included:
- Use NoTestRun to deploy without running tests.
- However, it is strongly recommended to run all Apex tests in the production org post-deployment to confirm no regressions were introduced.
Note: In some orgs, deploying flows may require Apex test coverage. If this applies, follow the same strategy as for Apex code changes (see Salesforce documentation for details).