# Know your real Apex coverage before release day does.

> SyncOnAI 360 Apex Test Coverage reports coverage from each org's last Apex test run, org-wide and for every class below 75%, excluding managed packages. The audit flags classes without tests and risky code, generated Apex ships with tests, and every proposal checks whether it can pass Salesforce's coverage gate.

Source: https://synconai360.com/features/apex-coverage

## Key facts

- **75%**: Salesforce's production coverage bar, checked per class
- **9**: Apex and code checks in the audit
- **0%**: Never shown when no test run exists; it says Not recorded
- **1**: Coverage check on every proposal with Apex

## Why Apex coverage surprises teams at the worst moment

Salesforce requires coverage for production deploys, and most teams only look at the number when a deploy fails. By then the release is blocked and the fix is a rushed test that asserts nothing.

- **Coverage seen too late.** The real number is discovered when a production deploy fails on coverage.
- **Org-wide averages hide problems.** A healthy average can hide individual classes with no meaningful tests at all.
- **Zero versus unknown.** Tools that show 0% when no test run exists send teams chasing the wrong problem.
- **Tests written last.** Tests added under deadline pressure cover lines without checking behaviour.

## How is Apex test coverage measured in SyncOnAI 360?

Coverage comes from the org's own last Apex test run: the org-wide figure and every class below 75%. Managed package classes are left out, because they are not yours to test.

If the org has no test run recorded, the page says Not recorded rather than 0%. Run your tests in Salesforce, or ask the chat to run them, refresh the org, and the figure updates.

- Org-wide and per-class coverage
- Managed packages excluded
- Not recorded when there is no run

## Which Apex code-quality issues are flagged?

The audit's Apex section checks for classes without a test class, coverage under 75%, SOQL and DML inside loops, hardcoded ids and URLs, ancient API versions, empty catch blocks, oversized classes and more than one trigger per object.

Each finding opens to the Apex source lines behind it, with a severity and an effort estimate, and can be sent to the chat to draft a fix as a proposal.

- Missing tests and low coverage
- SOQL and DML in loops
- Hardcoded ids, empty catches, old API versions
- Multiple triggers per object

## Will a deploy pass Salesforce's coverage gate?

Every proposal containing Apex runs a test coverage check. If it carries its own tests, Salesforce will run those in production and needs each deployed class covered. If it carries none, Salesforce runs every test in the org and needs the overall average at the bar, and the check warns you before you find out the hard way.

Production deploys that include Apex run its tests at Salesforce's 75% bar. A Developer Edition org counts as production for this.

- Coverage checked before deploy
- Warns when a proposal carries no tests
- Tests run on production deploys

## How does SyncOnAI 360 help raise Apex coverage?

Generated Apex comes with tests, built around the org's own patterns, and a component can be proposed together with its controller and its test as one change. The Apex Engineer agent writes classes, triggers and tests on request.

Audit findings for missing tests can be turned into work items or sent to the chat, so raising coverage becomes planned work rather than a release-day scramble.

- Tests with generated Apex
- Apex Engineer agent
- Coverage gaps as planned work

## How should Apex coverage be raised in an existing org?

Start with the classes the audit flags for missing or weak tests, ordered by severity and effort, rather than chasing the overall percentage. Turning those findings into work items gives the team a plan it can work through between releases.

Each test written goes through a proposal and is validated against the org, so coverage rises with tests that actually run, and the next refresh after a test run shows the new figure.

- Start from flagged classes
- Plan it as work items
- Tests validated against the org

## Raising coverage

1. **Measure.** Read coverage from the org's last test run.
2. **Find.** See every class under the bar and the quality findings.
3. **Write.** Draft tests with the Apex Engineer agent.
4. **Check.** Proposals warn when coverage may fail.
5. **Deploy.** Tests run on production, and the receipt records it.

## Coverage, with and without SyncOnAI 360

| Without | With SyncOnAI 360 |
|---|---|
| Found out when a deploy fails | Known from the last test run, class by class |
| 0% when nothing ran | Not recorded, until tests actually run |
| Averages hiding untested classes | Every class under the bar named |
| Tests written last | Tests proposed with the code |
| No warning before the gate | A coverage check on every Apex proposal |

## Who uses Apex coverage and quality

- **Salesforce developers.** See coverage from the org's last test run and the code-quality issues behind it, each opened to the source lines, and draft fixes and tests as proposals.
- **Release managers and approvers.** Know before deploy day whether a change will pass Salesforce's coverage gate, because every proposal with Apex runs a coverage check and warns when it will not.
- **Consultancies.** Show a client exactly where coverage stands, Not recorded where no run exists rather than a misleading zero, and turn missing tests into planned, priced work.
- **Salesforce admins.** Ask the chat to run the org's tests, refresh the org and read the updated figure, without opening developer tooling.
- **Salesforce architects.** See where test coverage is thin across the org's code before planning a refactor, so the riskiest classes get tests first.

## Frequently asked questions

### Where does the coverage number come from?

From the org's own last Apex test run, org-wide and per class, excluding managed package classes.

### Why does it say Not recorded?

Because the org has no Apex test run recorded. Run tests and refresh the org to see coverage.

### What coverage does Salesforce require?

Salesforce requires 75% coverage for production deploys that include Apex.

### Can it tell me if a deploy will fail coverage?

Every proposal with Apex runs a coverage check and warns when it carries no tests of its own.

### Can AI write Apex tests?

Yes. Generated Apex comes with tests, and the Apex Engineer agent writes tests on request.

### Can it run our tests?

Yes. Apex test runs are part of live org access.

### Which code-quality issues are flagged?

Missing tests, low coverage, SOQL and DML in loops, hardcoded ids, old API versions, empty catches, oversized classes and multiple triggers per object.

### Is coverage analysis on every plan?

Yes. Every plan includes every feature.