Skip to main content

SF-0259 · Scenario · Medium

What happens if code coverage is less than 75%?

✓ Verified by Vikas Singhal · Last reviewed 5/17/2026 · Updated for Spring '26

The platform refuses the deploy. There’s no override, no “deploy anyway” flag, no support case that gets you past it. The 75% threshold is a hard production gate.

The error from the deploy log looks like:

Code coverage issue. Average test coverage across all Apex Classes
and Triggers is X%, at least 75% test coverage is required.

Or, for a per-trigger violation:

Code coverage issue. Trigger AccountTrigger has 0% test coverage,
at least 1% test coverage is required.

What stops working

  • No Apex changes deploy to production. Even a one-line fix is blocked.
  • No new Apex classes or triggers. They’re still developed in sandbox; you just can’t ship.
  • Metadata-only deployments (no Apex) still succeed — the rule only triggers when Apex is in the deployment.

A scary side-effect: if you delete tests in a deployment and the remaining org-wide coverage drops below 75%, the deletion itself fails. You’d have to add tests back before you can remove them.

How to fix it

Three honest options, in order of how much you should pick them:

1. Write more tests (the only good option)

Identify which classes have low coverage:

  • Developer Console → Tests → Code Coverage.
  • VS Code → run tests → coverage gutters.
  • sf apex run test --code-coverage --result-format human.

Pick the classes with the lowest coverage that are doing real work (not test mocks or wrappers). Write tests that:

  • Exercise the code path — call the methods with realistic inputs.
  • Assert the outcomes — System.assertEquals, System.assert.
  • Cover both happy path and edge cases — null inputs, empty lists, validation failures, governor-limit boundaries.

A test that runs the code without asserting will boost coverage and provide zero defence against regressions. Real tests beat padding every time.

2. Remove dead code

Sometimes the easiest 5% comes from deleting Apex nobody calls anymore. Old class? Old @deprecated method? Drop it from the deployment.

Be careful: removing a class with high coverage and low usage can lower coverage rather than raise it, because the denominator shrinks faster than the numerator. Re-run the coverage analysis after deletion.

3. Deploy without Apex

If the deployment that’s stuck happens to include declarative-only changes (fields, layouts, flows), strip the Apex from the change set and deploy the declarative bits first. Tackle the coverage gap separately.

What you should NOT do

  • @isTest everything that isn’t a real test to game the metric. It works as a temporary cheat, but reviewers will (and should) catch it.
  • Run an empty test that just calls every method. “Coverage padding”. Misses the entire point of testing.
  • Try to disable tests for the deployment. Run Local Tests is mandatory for production. You can’t skip.

The trigger-specific trap

Every trigger needs at least 1% coverage. A brand-new trigger with no tests at all blocks production deploy even if the org is at 90% overall. Always write the test alongside the trigger.

How long does fixing take

For a single under-covered class:

  • Reading the code to understand what it does: 20–60 minutes.
  • Writing 3–5 meaningful tests: 1–3 hours.
  • Running and iterating: 30 minutes.

Budget half a day per class that’s badly under-covered. Multiply by the number of weak classes. Coverage debt accumulated over months can take days to repay.

Prevention

Bake the rule into CI:

  • Run sf project deploy validate --test-level RunLocalTests against a sandbox on every PR.
  • Reject the PR if org-wide coverage drops.
  • Use CI reporting (Gearset, Copado, custom Tooling-API queries) to track coverage per class over time.

Most production-coverage emergencies happen because the team only checked coverage at deploy time. Checking on every PR moves the failure cost from “release day” to “PR review”.

In an interview

The clean answer: “Salesforce blocks the production deploy. The error is Code coverage less than 75%. The fix is to add meaningful tests to the under-covered classes — there’s no override or workaround. We prevent this by validating coverage in CI on every PR.”

Verified against: Apex Developer Guide — Code Coverage, Salesforce Help — Deploying Apex, Metadata API Developer Guide, Salesforce DX Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.