Test Case Coverage
Test case coverage, usually called Apex code coverage, is a metric that reports the percentage of executable Apex lines run by your unit tests during a test execution.
Definition
Test case coverage, usually called Apex code coverage, is a metric that reports the percentage of executable Apex lines run by your unit tests during a test execution. Salesforce tracks it per class and trigger, and also as a single org-wide number.
The platform enforces a hard rule. At least 75 percent of your Apex must be covered, and every trigger needs some coverage, before you can deploy to production or package code for AppExchange. The number is a gate for shipping, not a measure of test quality on its own.
How Salesforce counts the lines
What the percentage actually measures
Coverage is a simple division. Salesforce takes the number of executable Apex lines that your tests run, divides by the total number of executable lines, and reports the result as a percentage. A class with 100 executable lines where tests touch 80 of them shows 80 percent. Not every line counts toward the denominator. Comments, blank lines, and lone curly braces are ignored. Method signatures and class declarations are not executable in the coverage sense. Lines inside your test methods themselves do not count toward the code being measured, since the point is to verify production logic, not the tests. The metric is purely about execution. A line is covered the moment a test causes it to run, whether or not the test checks the outcome. This is the gap most teams miss. You can reach 90 percent coverage with zero assertions and prove almost nothing about whether the code is correct. Coverage tells you what ran. It does not tell you what was verified.
The 75 percent rule and where it bites
The 75 percent requirement applies at the org level when you deploy to a production environment. It also applies when you upload a managed or unmanaged package. Below that line, the deployment is rejected outright. Two extra conditions ride alongside the percentage. Every trigger must have at least some test coverage, even a single line, or the deployment fails regardless of the overall number. And all tests that run during deployment must pass. One failing assertion blocks the whole release. Sandboxes are more forgiving. You can save individual classes in a Developer or Developer Pro sandbox without hitting the 75 percent bar, which is why coverage problems often surface late, at the moment someone tries to push to production. The rule is a floor for the entire org, not a per-class target, so a thin class can sit below 75 percent as long as the combined total clears the line. Many teams still hold each class to its own minimum to avoid surprises.
Org-wide coverage versus per-class coverage
Salesforce reports coverage at two levels. Per-class coverage shows up as a covered-over-total line count on each Apex class, plus blue and red line highlighting in the Developer Console that marks exactly which lines ran and which did not. The red lines are your to-do list. The org-wide number is the one that gates deployment. It rolls every relevant class into a single percentage. Managed package code is excluded from this overall figure, so a subscriber org is judged only on the code it actually owns and can change. That keeps a vendor's untested code from sinking your deployment, and it keeps their well-tested code from inflating your number. There is a timing detail worth knowing. The estimate shown by the Calculate Your Organization's Code Coverage link can read low if test classes were recently edited, because rows for changed classes get cleared until tests run again. Run all tests fresh before trusting any displayed total. The accurate number is the one produced by a full test run, not a cached estimate.
Why deployment coverage is never stored
When you run tests from the Developer Console or the Apex Test Execution page, Salesforce stores the results in coverage tables. Those records feed the per-class line counts and the highlighting you see afterward. Deployment is different. The coverage calculated during a deployment is computed on the spot and then discarded. It is not written to the coverage tables. The reason is rollback safety. If a deployment fails and rolls back, the classes and line numbers it referenced may no longer exist or may have shifted. Persisting coverage from a half-applied deployment would leave behind records that point at code that was never committed. This is why your stored coverage can look healthy while a deployment still reports a different figure. The deployment recalculates against the exact set of tests it chooses to run, which may be a subset (specified tests) rather than the full suite. If that subset exercises fewer lines, the deployment number drops even though your stored org-wide coverage looks fine.
Coverage is a floor, not a quality signal
Salesforce's own guidance is blunt about this. Do not chase the percentage. Aim instead to cover every use case your code supports, which naturally pushes coverage past 75 percent as a side effect rather than a goal. That means testing the paths that matter. Positive cases confirm the happy path works. Negative cases confirm bad input is rejected and the right errors are thrown. Bulk tests push 200 records through your logic to catch governor limit problems that a single-record test will never reveal. Tests that run as a restricted user catch sharing and permission failures that an admin-context test hides. A class at 100 percent coverage with no System.assert calls is a warning sign, not a win. It proves the lines run. It says nothing about whether the output is right. Strong test suites lead with assertions and treat the coverage number as a byproduct. The teams that get burned are the ones that wrote tests purely to clear the 75 percent gate, then trusted code that was never actually verified.
Reading and acting on a coverage report
The fastest way to find weak spots is the Developer Console. Run all tests, open the Tests tab, and select a class to see the overall percentage. The Code Coverage panel and the source highlighting show precisely which lines stayed red. Work the red lines in order of risk, not in order of convenience. An uncovered branch inside a trigger or a complex calculation matters more than an uncovered logging statement. For each red line, ask what input would make that path run, then write a test that supplies it and asserts the result. You can also pull coverage programmatically. The Tooling API exposes ApexCodeCoverage for per-class data and ApexOrgWideCoverage for the single org number, which is how CI pipelines fail a build that drops below a chosen threshold. Salesforce CLI surfaces the same figures during scratch org and package builds. Wiring a coverage check into your pipeline catches a regression at pull-request time, long before anyone tries to deploy to production and discovers the org has slipped under the line.
How to measure and improve Apex code coverage
Code coverage is not something you create. It is a number you measure by running tests, then improve by closing the gaps. Here is the loop for checking it and raising it in a sandbox or scratch org before you deploy.
- Open the Developer Console
From the gear menu in any org, choose Developer Console. This is the standard place to run Apex tests and read coverage without installing extra tooling.
- Run all tests
Choose Test, then New Run, and add the test classes you want, or use Run All. Letting the full suite run gives an accurate org-wide figure rather than the cached estimate.
- Read the overall and per-class numbers
Open the Tests tab and the Overall Code Coverage panel. Click any class to see its percentage and to highlight covered (blue) versus uncovered (red) lines in the source.
- Close the red lines with real tests
For each uncovered line, write a test that drives that path, then add System.assert calls to verify the outcome. Re-run tests and confirm both the line and the assertion pass.
Shows the org-wide percentage that gates deployment; this is the number that must clear 75 percent.
Blue lines ran during tests, red lines did not; red is your exact list of gaps to fix.
Run All recalculates the full org figure, while a selected run only reflects the lines those tests touch.
- Hitting 75 percent with no assertions passes the gate but verifies nothing; lead with System.assert.
- Every trigger needs at least some coverage, or deployment fails no matter how high the overall number is.
- The Calculate Your Organization's Code Coverage estimate reads low after editing test classes; run all tests for the real figure.
- Deployment coverage is recomputed against the tests it runs and is never stored, so it can differ from your sandbox number.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Test Case Coverage.
Hands-on resources to go deeper on Test Case Coverage.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Test Case Coverage?
Q2. What's the minimum for deployment?
Q3. Is 75% a good target?
Discussion
Loading discussion…