Tag: metadata api

Most Salesforce developers have been in a situation where the users have raised an urgent issue in production, which requires an immediate fix.  After the fix is developed, historically to deploy it to production you would have to wait for all the tests in your org to run, this can range from 30 minutes to 6-7 hours (maybe even more).

Now using testLevel attribute in the build.xml, only the contents of the deployment package needs to have at least 75% coverage. For example if you’re deploying myController class, you need to specify which test class(es) give at least 75% test coverage for only that class.  This can significantly reduce deployment time, I’ve seen production deployments happen in less than a minute!

In this blog I will give a walk through on how to use the testLevel attribute.

What deployment methods support this?
As this is part of the Metadata API (API Version 34), only tools that use the Metadata API support this functionality. This includes the Force.com Migration Tool.  Unfortunately this does not include Change Sets.

What value can the testLevel be set to?
The testlevel attribute can be set to one of four levels:

1. NoTestRun – This option is only applicable when deploying to development environments (e.g. Sandboxes and Developer Editions). When this level is selected no tests are run.
2. RunLocalTests – This option is default for production deployments (only ones which have classes or triggers as part of the deployment package). When RunLocalTests is set, all tests are run apart from  ones which are part of managed packages are run.
3. RunSpecifiedTests – When selecting this option, only tests specified in the runtests tags are executed (more about  this later on).  This option is useful when doing partial deployments or applying fixes.  Each class or trigger in the deployment package must have atleast 75% coverage.  This option significantly reduces deployment time as only a sub set of tests are run.  If this option is selected then you must specify the tests that need to be executed using the runtest tag.
4. RunAllTestsInOrg – This option does what it says on the tin, all tests in your org are executed, even the ones which are part of managed packages.

Note: By default if the deployment package does not contain any Apex components (classes and triggers) then no tests are run.

What does the Build.xml look like?

So now you’ve developed your fix and you are ready to deploy.  The ant build file change is pretty simple. Here is a snippet of a sample build file:

As you can see the testLevel is set to run RunSpecifiedTests. And within the sf:deploy tag is where the tests to run are specified. In this example myControllerTest, anotherControllerTest, myOtherController and myPageControllerTest are only executed.

This next build file example is if your package does not contain any classes or triggers (e.g. It only contains visualforce pages or other components).

As you can see above,  there is no testLevel attribute and as the package does not contain any apex classes or triggers, no tests are run.

So there you have it, a quick walk through on how to use the testLevel attribute to speed up deployments to production!