In a previous post I discussed why Apex Test code is a good thing and how the creation of test data could be managed using an Apex test code generation tool. In this post I shall discuss how we can use the recently released Tooling API to maintain detailed knowledge on how our test code is evolving over time; which classes and triggers need more work; and how classes contribute to the overall test code coverage in your org.

With Winter ’14 we released the new Tooling API, which (amongst other things) allowed us access to a number of new objects in our Salesforce org which store code coverage information. The Developer console uses these objects to show us the number of covered and uncovered lines, as well as the details of which test classes contribute to code coverage.

An Apex Test Code Coverage Tool

For the first time, the tooling API provides us with an easy way to extract this data from your target org – in particular from the ApexCodeCoverage and ApexCodeCoverageAggregate objects – and with that it allows you to develop tools which store and manipulate this data.

I was recently working on a project where, as part of a development sprint, a significant amount of code was added. As a part of this project we looked at a way of keeping track of how test code development was keeping up with the code. During this project we developed a simple tool that stores this data in a CSV file, which thereby allows us to open and maintain this data using spreadsheets.

The tool that we developed can be found here (this is not an official / Salesforce supported product).  It was developed in Java and both the source, JAR and exe can be found. The way the tool works:

• It accepts a number of command line arguments including
  • Login (-u)
  • Password (Don’t forget your access token!) (-p)
  • Authentication End Point (-a)
• It uses the REST Tooling Api to retrieve code coverage details from the Org
• It stores the resulting coverage data in a CSV file

We used this tool to gather data on a daily basis during the development cycle, allowing us to compare coverage results over time and where necessary re-focus our test code development.

By default this tool lists all classes and lines covered / not covered by test code. If you specify class or trigger names as command line arguments (-c), it will show (for those classes/triggers) which test classes contribute to the coverage for these classes instead. As a result, you can analyse in detail where you test code is (and isn’t) coming from.

When using this tool please note that:

• The number of Apex classes in our org was not high enough to trigger batched results being returned by the Rest API so this part was never tested. If you run into issues there – give me some sample data and I’ll update the code
• If (in your spreadsheet) you add up the total number of lines covered, uncovered and in total, you can calculate the total test code coverage of your org. Whilst this calculation is not identical to the one used in your Salesforce org, this method has given us pretty accurate results.
• There was an issue in Winter ’14 where some classes made invalid contributions to the overall test coverage results. Use the output of this tool to determine which of these classes have no test coverage and add at least 1% coverage to these classes and triggers to avoid this issue.