The 75% Apex code coverage rule, explained

August 3, 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

The 75% is an aggregate: total covered lines across your Apex divided by total lines, not a per-class bar. One big uncovered class can sink an otherwise well-tested org.
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 don't enforce it. That's why a deploy that worked all week in your sandbox fails the moment it heads to production - production (and check-only validations against production) is where the gate 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, runs a check-only validation with the full coverage report before anything touches your org, and blocks the deploy below the gate (75% by default) - so the production rule is enforced while you're still in the sandbox. How the deploy pipeline works →