Choose Which Tests to Run in a Deployment

Test levels enable you to have more control over which tests are run in a deployment. To shorten deployment time to production, run a subset of tests when deploying Apex components. The default test execution behavior in production has also changed. By default, if no test level is specified, no tests are executed, unless your deployment package contains Apex classes or triggers.

As part of this change, the runAllTests deployment option is now replaced with testLevel. You can choose which tests to run in a deployment by setting the desired test level. For a description of all test levels, see test levels for the deploy() call. In particular, to run a subset of tests in a deployment, set testLevel to the RunSpecifiedTests value and specify the tests to run in the runTests option.

When running a subset of tests, code coverage is computed for each class and trigger individually and is different than the overall coverage percentage. If your deployment package contains Apex classes and triggers, the executed tests must cover each class and trigger for a minimum of 75% code coverage.

If the code coverage of an Apex component in the deployment is less than 75%, the deployment fails. If one of the specified tests fails, the deployment also fails. We recommend that you test your deployment in sandbox first to ensure that the specified tests cover each component sufficiently. Even if your organization’s overall code coverage is 75% or more, the individual coverage of the Apex components being deployed can be less. If the code coverage requirement isn’t met, write more tests and include them in the deployment.

This change is in the Metadata API and is exposed in tools that are based on Metadata API, such as the Force.com Migration Tool.

Specify Tests in the Force.com Migration Tool

To run a subset of tests in the Force.com Migration Tool, add the testLevel="RunSpecifiedTests" parameter to the deploy target. Specify each test class to run for a deploy target in a <runTest> </runTest> child element within the sf:deploy element. Add the test class name within the <runTest> </runTest> tags. Add as many runTest tags as you need, one for each test class.

This deploy target example shows three test classes. Salesforce runs these test classes when deploying this package.

<target name="deployCode">
    <sf:deploy username="${sf.username}" password="${sf.password}" 
           sessionId="${sf.sessionId}" serverurl="${sf.serverurl}"
           deployroot="codepkg" testLevel="RunSpecifiedTests">
        <runTest>TestClass1</runTest>
        <runTest>TestClass2</runTest>
        <runTest>TestClass3</runTest>
    </sf:deploy>
</target>

Specify Tests in Metadata API

To run a subset of tests by using the Metadata API, set the RunSpecifiedTests test level on the DeployOptions object. Next, specify each test class to run in DeployOptions. Finally, pass DeployOptions as an argument to the deploy() call. The following example performs those steps to run only the specified test classes.

// Create the DeployOptions object.
DeployOptions deployOptions = new DeployOptions();

// Set the appropriate test level.
deployOptions.setTestLevel(TestLevel.RunSpecifiedTests);

// Specify the test classes to run.
// String array contains test class names.
String[] tests = {"TestClass1", "TestClass2", "TestClass3"};
// Add the test class names array to the deployment options.
deployOptions.setRunTests(tests);

// Call deploy() by passing the deployment options object as an argument. 
AsyncResult asyncResult = metadatabinding.deploy(zipBytes,deployOptions);

Considerations for Running Specific Tests

  • You can only specify test classes. You can’t specify individual test methods.
  • We recommend that you refactor test classes to include the minimum number of tests that meet code coverage requirements. Refactoring your test classes can contribute to shorter test execution times, and as a result, shorter deployment times.
  • You can deactivate a trigger in the target organization by deploying it with an inactive state. However, the trigger must have been previously deployed with an active state.

Default Test Execution in Production

When no test level is specified in the deployment options, the default test execution behavior depends on the contents of your deployment package. When deploying to production, all tests, except those that originate from managed packages, are executed if your deployment package contains Apex classes or triggers. If your package doesn’t contain Apex components, no tests are run by default.

In API version 33.0 and earlier, tests were run for components that required tests, such as custom objects, and not only for Apex components. For example, if your package contains a custom object, all tests are run in API version 33.0 and earlier. In contrast, starting with API version 34.0, no tests are run for this package. The API version corresponds to the version of your API client or the version of the tool you’re using (Force.com Migration Tool).

You can run tests for a deployment of non-Apex components. You can override the default test execution behavior by setting the test level in your deployment options. Test levels are enforced regardless of the types of components present in your deployment package. We recommend that you run all local tests in your development environment, such as sandbox, prior to deploying to production. Running tests in your development environment reduces the amount of tests needed to run in a production deployment.