The 75% Apex code coverage rule, explained

September 24, 2026

Salesforce will not deploy Apex to production unless your tests cover at least 75% of the code being deployed, and every trigger has at least some coverage. Hit a deploy failure like "Average test coverage across all Apex Classes and Triggers is 68%, at least 75% test coverage is required" and this rule is what you've met.

What the rule actually is

Which 75% depends on the tests you run. Run all local tests (the default for production) and it is an aggregate: total covered lines across your Apex divided by total lines - one big uncovered class can sink an otherwise well-tested org. Run only named tests (RunSpecifiedTests, how most targeted deploys work) and it is computed per class and trigger: each one in the deploy needs 75% on its own.
Every trigger needs at least one covered line - a trigger with 0% blocks the deploy on its own, regardless of the average.
Only executable lines count. Comments, blank lines, and declarations aren't in the denominator.
Sandboxes only enforce it when a deploy runs tests. That's why a deploy that worked all week in your sandbox fails the moment it heads to production - production always runs tests for Apex (and so do check-only validations against it), so that is where the gate reliably lives.

Why Salesforce enforces it

Apex runs on shared infrastructure inside a multi-tenant platform - your code executes next to thousands of other orgs'. The coverage rule is a crude but effective forcing function: it guarantees every org ships some automated verification with its code. Crude, because coverage measures execution, not correctness - a test with no assertions still "covers" lines. Effective, because in practice orgs with real tests catch real regressions.

How to raise coverage without writing junk tests

The anti-pattern is the "coverage test": call every method, assert nothing. It satisfies the number and catches nothing. Better:

Test behavior, not lines. One test that creates a record, runs your logic, and asserts the outcome usually covers more lines than three tests poking at getters - and it fails when the logic breaks.
Use @TestSetup to build shared test data once per class. Tests run faster and stay consistent.
Never rely on org data. SeeAllData=true makes tests fail in other orgs (and in production, where the data differs). Create what you need inside the test.
Test in bulk. Insert 200 records, not 1 - governor-limit bugs only appear at volume, and bulk tests cover the loops that single-record tests skip.
Mock callouts with HttpCalloutMock - tests can't make real HTTP requests, so uncovered callout code is often what's dragging the average down.
Assert with System.runAs where sharing matters, so permission regressions fail a test instead of a user.

Checking before you deploy

Run your tests with coverage in your sandbox first (Setup → Apex Test Execution, or sf apex run test --code-coverage), and validate against production with a check-only deploy - it runs the full test suite and reports coverage without changing anything. If the check passes, the real deploy will too.

---

OrgTide generates every Apex class with a matching test class and runs those tests inside every deploy - a failing test stops it. A one-click sandbox deploy that passes but covers too little still lands, marked "coverage too low for production"; a check, a release deploy or a promotion is held to 75%, so under-covered Apex never reaches production. How deploys work →