Code coverage is the percentage of executable Apex lines actually run when your test classes execute. If your class has 100 lines of executable code and your tests touch 80 of them, that class has 80% coverage.
In Salesforce the metric is enforced at deployment time: the entire org must be at 75% or higher for Apex to deploy to production. It’s a hard gate, not a recommendation.
The exact rule
When you deploy Apex to production, Salesforce calculates:
org-wide coverage = (executable lines covered by tests) / (total executable lines in the org)If that number is below 75%, the deploy fails with Code coverage less than 75%.
A second rule rides along: every individual trigger must have at least 1% coverage. A trigger with zero coverage blocks the deploy even if the org is at 90% overall.
And the unspoken third rule: all tests must pass. A test that throws — even on a class outside the deployment — fails the production deploy.
What counts and what doesn’t
Counted in the denominator (executable lines):
- Apex statements, method calls, control flow
- Initialisations
- Loop bodies
Not counted:
- Comments
- Blank lines
// no-opstyle placeholders- Test class methods themselves (you don’t test the tests)
- Code marked with
@isTest - Some declaration-only lines (like a class header)
Why 75%
The platform’s design intent: forcing tests means forcing developers to think about expected behaviour. The 75% threshold is high enough to be meaningful, low enough to allow real-world projects to ship. It’s been the rule since the beginning and isn’t changing.
How to view coverage
- Developer Console: Tests menu → Code Coverage. Shows per-class coverage.
- VS Code with Salesforce Extensions: the test runner shows per-line gutters indicating covered/uncovered lines.
- Apex Test Execution in Setup → Apex Test Execution → Run Tests, then view results.
- Tooling API /
ApexCodeCoverageAggregate: programmatic access for CI dashboards. sf apex test run --result-format humanon the command line.
Per-class vs org-wide
The platform enforces org-wide coverage at deploy time, but individual classes can be anywhere:
- A class at 30% is fine as long as the org average is 75%+.
- A class at 100% can offset a class at 50%.
Some teams adopt internal standards of “every class > 75%” or “every class > 85%” for quality reasons, enforced via CI before the deploy is even attempted.
How to raise coverage
The healthy way: write meaningful unit tests that exercise the code path and assert expected outputs.
@isTest
private class AccountTriggerTest {
@isTest
static void shouldSetDefaultRatingOnInsert() {
Account a = new Account(Name = 'Acme');
insert a;
Account inserted = [SELECT Rating FROM Account WHERE Id = :a.Id];
System.assertEquals('Cold', inserted.Rating);
}
}The unhealthy way: coverage-padding — calling methods without asserting anything just to bump the percentage. This is a code-review red flag in serious teams; tests that don’t assert give you no defence against regressions, just deploy permission.
Things that surprise people
- Test classes themselves contribute zero to coverage. They run code but aren’t measured.
- Failed tests still count their covered lines. Coverage is calculated from what executed; passing tests aren’t required for the lines to count.
- Coverage data lives in
ApexCodeCoveragein the Tooling API — queryable. - Old coverage data goes stale. If you haven’t run tests in a while, the cached coverage can be wrong. Run All Local Tests before a deploy to refresh.
What if coverage drops below 75%
Deploy fails. See What happens if code coverage is less than 75%? for the recovery options.
Verified against: Apex Developer Guide — Code Coverage, Salesforce Help — Deploying Apex, Salesforce DX Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.