Skip to main content

Code coverage in pipelines

Code coverage per feature is displayed in pipelines, aiding pre-merge quality gates

Written by Jacob Joshua

Gearset can run Apex unit tests as part of the validation of features in your pipeline. When tests run, Gearset reports the overall code coverage result and, when available, a per-class breakdown for Apex classes and triggers.

In the below example, feature TN-4059[...] is queued & ready to merge into my Pre-Prod environment. The coverage from the validation reports back at 95.6% 🎉

When per-class coverage information is available, you’ll see a Code coverage tab in deployment, validation, and CI job results. This tab can appear for both successful and failed runs.

The Code coverage tab shows:

  • Overall code coverage as a percentage

  • Each Apex class or trigger that Gearset has coverage information for

  • The individual coverage percentage for each item

  • The number of covered locations as shown in the example below.

This makes it easier to identify which specific classes or triggers have low coverage, especially when a deployment or validation fails because it doesn’t meet Salesforce’s code coverage requirements.

Note: The per class breakdown appears in Gearset result screens, but isn’t currently included in PDF deployment reports. This may be added in a future update.

Which classes are being checked?

This depends on the Apex test level specified in the underlying CI job. The test level determines which Apex tests Gearset runs, which then affects the coverage results shown for the related Apex classes. Consider these two examples:

Example 1

  • The CI job's validation is set to: "Run tests > Specify tests to run > Tests that match naming conventions for Apex changes in the deployment"


    You can configure it in the Test section of your CI job.

  • In my feature branch I commit ClassA and ClassATest, as I want to deploy these classes to Pre-Prod. No other changes are committed.​

  • Due to the testing level in my CI job, Gearset automatically picks up ClassATest as a component I committed, and runs that test only.​

  • Code coverage on that class comes back at 89%

Example 2

  • The CI job validation is set to "Run tests: All your tests" (as on below image).

  • Similar to Example 1, I commit ClassA and ClassATest to my feature branch.

  • Gearset will run ClassATest along with all other Apex tests in the target org.

  • Code coverage comes back at 95.6% (the 89% from ClassATest + the result of all tests classes combined in the org)

Why code coverage matters

Code coverage helps teams assess the quality and readiness of Apex changes before they’re promoted through a pipeline. Salesforce requires a minimum of 75% coverage for Apex classes deployed to Production, but many teams set a higher internal target to give themselves greater confidence in the changes being released.

For example, a team might aim for 85% coverage before approving pipeline work, giving reviewers more confidence that the changes are ready to progress.

Understanding code coverage results

  • Apex tests will kick off automatically as soon as a feature targets a pipelines environment, provided that the Validate pull requests option is enabled in your CI job.

    The following must also complete and pass first in order for the code coverage check to trigger:

  • Code coverage is calculated against the Salesforce org that Gearset is validating or deploying to, which is usually the target org. This means the result may differ from coverage seen in a development org, especially if the target org has different Apex classes, test classes, or stored coverage data.

  • Salesforce stores total code coverage as a cumulative value since the last reset. This reset happens automatically during each deployment, but can also be done manually in the target org. Resetting coverage can help ensure the metrics reflect the latest state of that org.

  • The per-class breakdown only includes coverage information Gearset receives from Salesforce for that deployment, validation, or CI run. Classes or triggers without coverage from the selected tests may show low or 0% coverage, which can affect the overall percentage. It’s important to choose an appropriate testing level for your sandbox or org requirements.

  • As a best practice, consider requiring Apex classes included in a PR to be accompanied by a test class. This can be checked manually during review by the people approving the work.

  • If your CI job is set to Run tests: All your tests, Gearset runs all Apex tests in the target org. Classes without coverage from those test runs may show as 0%, which can affect the overall coverage result.

  • The Specify tests to run option gives you more control over which Apex tests Gearset runs. This can help focus code coverage results on the classes relevant to your deployment.

Related Articles
Did this answer your question?