Salesforce requires 75% Apex test coverage to deploy to production. Most IT Directors treat that number as a quality gate. It isn't. A test class can execute every line of a trigger, satisfy the org-wide requirement, and still assert nothing about what the code actually does. Coverage measures execution, not correctness, and that gap is where production incidents come from.
The 75% Threshold Is a Compliance Checkbox, Not a Safety Net
Salesforce set the 75% bar as a deployment gate, not a quality standard. It exists to stop orgs from shipping completely untested metadata, nothing more. Teams under release pressure learn to satisfy the number fast: wrap a method in a try block, call it once, move on. The deploy goes through. The bug ships anyway.
We see this constantly in CPQ and Service Cloud orgs where complex trigger logic handles pricing or case routing. A test class hits 92% coverage on a 400-line trigger handler but contains zero assert statements tied to business outcomes. The pipeline is green. The logic is unverified.
This matters more as orgs lean on Agentforce and automation that touches live customer data. A coverage percentage tells a release manager nothing about whether a flow still routes the right case to the right queue after a field update. It only confirms the code ran without throwing an unhandled exception.
What High Coverage Actually Hides
Three failure patterns show up again and again in orgs that treat coverage as the finish line.
First, tests that create their own data inline, often a single Account and a single Contact, never touching the edge cases that exist in real records: null fields, long text values, duplicate email addresses, mismatched record types. The test passes because the data was built to make it pass.
Second, bulk failures. A trigger works fine for one record and collapses at 200, hitting governor limits or SOQL-in-a-loop errors that never surface in a test running against a handful of rows. Coverage percentage has no concept of volume.
Third, negative-path blindness. Teams write tests for the happy path because that's what gets coverage numbers up fastest. Nobody tests what happens when a required field is blank, an API callout times out, or a user without the right permission set tries to trigger the flow. Those are exactly the paths that break in production.
The Sandbox Data Problem Nobody Talks About
Here's the part most coverage conversations skip entirely: test quality is downstream of data quality. You can write a perfect assertion, but if your sandbox has eleven Account records and your production org has eleven million, the test tells you nothing about real-world behavior.
Developers writing Apex tests against thin sandboxes default to inline test data because there's nothing realistic to query against. That's how you end up with tests that pass against a clean, synthetic dataset and fail the moment the deployment touches production-scale volume, duplicate records, or the messy field combinations that accumulate over years of user input.
This is precisely why we built SproutEzee. It generates production-like data at production-like volume inside a sandbox, so a test class querying 5,000 Opportunity records behaves the same way in QA as it will in prod. When your test data mirrors reality, your coverage numbers start meaning something. When it doesn't, 75% is theater.
Assertions vs Execution: The Metric That Matters
If you want a single metric that predicts release risk better than coverage percentage, count assertions per test method and tie them to business rules, not code paths.
| Metric | What It Measures | What It Misses |
|---|---|---|
| Line coverage % | Whether a line of code executed | Whether the output was correct |
| Assertion density | Whether behavior was verified | Nothing if assertions are weak (e.g. assertNotNull only) |
| Bulk test pass rate | Behavior at 200+ records | Governor limit edge cases beyond tested volume |
| Negative path coverage | Error handling and validation | Permission and sharing rule interactions |
A test suite with 80% line coverage and strong assertion density across bulk and negative paths is safer than one sitting at 95% with single-record happy-path tests. Release managers who only track the Salesforce-reported percentage are flying with half the instrument panel.
Building a Coverage Strategy That Catches Real Bugs
Fix this in four concrete moves, not a policy memo nobody reads.
- Require assertions on outcomes, not just execution. A test verifying a trigger updates a field needs to assert the new value, not just confirm the method ran.
- Mandate bulk tests for any trigger or flow touching more than one object. Test with 200 records minimum, matching Salesforce's own batch size default.
- Build negative-path tests into the definition of done. If a feature has three failure modes, write three tests for them before calling the story complete.
- Run tests against realistic sandbox data, not inline fixtures built to pass. This is the single highest-leverage change, since it exposes the bugs that only exist at scale.
None of this requires new tooling in most orgs. It requires a code review standard that actually checks for assertion quality and a sandbox strategy that gives developers something real to test against. The second half is where most teams quietly fail, because refreshing a full sandbox with usable, compliant data takes days most release calendars don't have.
How DeployEzee and SproutEzee Change the Equation
Our deployment platform, DeployEzee, enforces coverage gates as part of the pipeline, but we pair it with SproutEzee specifically so those gates mean something. Developers get production-like volume and variety in their sandbox before they write a single test, which pushes assertion quality up without anyone having to argue about it in a code review.
MaskEzee handles the compliance side of that same data, so realistic test data doesn't mean exposed customer records sitting in a QA org. The combination means a team can run bulk tests against 50,000 masked, production-shaped records in a sandbox refreshed overnight, instead of hand-building fixtures that quietly bias every test toward passing.
Coverage percentage will keep being the number Salesforce checks at deploy time. That's fine. The mistake is letting it be the number your team checks for confidence. Track assertion quality, bulk behavior, and negative-path coverage alongside it, and 75% stops being a compliance checkbox and starts being an actual floor under your release risk.
Frequently Asked Questions
Is 75% Apex test coverage enough for a safe deployment?
No. 75% is Salesforce's minimum requirement to allow a deployment, not a quality benchmark. Orgs regularly pass this threshold with tests that execute code without verifying correct behavior, which means bugs tied to bulk volume or edge-case data routinely slip through.
Why do high-coverage Apex tests still miss bugs?
Most coverage gaps come from tests that assert execution rather than outcomes, use thin single-record data instead of bulk volume, and skip negative paths like blank fields or permission errors. A test can run every line of a trigger and still never check whether the output is correct.
How does sandbox data quality affect Apex test reliability?
Tests written against thin, unrealistic sandbox data often pass in QA and fail in production because they never encounter duplicate records, null values, or volume above a handful of rows. Using production-like data at realistic scale, generated through a tool like SproutEzee, exposes the same failure modes your tests will face in production before deployment.
What should teams measure instead of just coverage percentage?
Assertion density tied to business outcomes, bulk test pass rates at 200+ records, and negative-path coverage for error handling all predict release risk better than line coverage alone. A team tracking these alongside the standard percentage catches regressions that a coverage-only gate misses.
Can masked production data be used safely in Apex test classes?
Yes, and it's the recommended approach for enterprise orgs handling regulated customer data. Tools like MaskEzee scramble sensitive fields while preserving realistic data shapes and relationships, so Apex tests run against production-like volume without exposing real customer records in a sandbox.