# How to raise Apex test coverage above 75%, with tests that mean something.

> Raising Apex coverage with SyncOnAI 360 means reading coverage from the org's last test run, finding the classes the audit flags for missing or weak tests, generating tests around the org's own patterns, and shipping them as validated proposals, with every proposal checked against Salesforce's 75% production gate.

Source: https://synconai360.com/use-cases/apex-test-coverage

## Key facts

- **75%**: Salesforce's production coverage gate
- **Every**: Proposal with Apex runs a coverage check
- **Not recorded**: Shown when no test run exists, never 0%
- **1**: Change for a class and its test

## Why coverage becomes a deploy-day emergency

Coverage is ignored until a production deploy fails the gate. Then someone writes tests that execute lines without checking anything, just to get over the bar.

- **Found at deploy.** The coverage failure appears in the release window.
- **Hollow tests.** Tests written to execute lines, not to check behaviour.
- **No priority.** Nobody knows which classes matter most.
- **Unknown baseline.** Coverage figures are old or missing.

## Where does the Apex coverage figure come from?

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

- From the last test run
- Not recorded, never a false zero
- Run tests from the chat

## Which classes should get tests first?

The audit's Apex section flags missing or weak tests alongside code-quality issues such as SOQL in loops and hardcoded ids, each opened to the source lines, with severity and effort. Start with severe, quick items rather than chasing the overall percentage.

- Uncovered classes flagged
- Code-quality issues beside them
- Severity and effort

## How do you generate Apex tests that fit the org?

Ask the Apex Engineer agent or the chat to write tests for a class. Generated Apex comes with tests built around the org's own patterns, and Apex Logic refuses edits that would not compile.

Review the test like any other code before it ships: the goal is behaviour checked, not lines executed.

- Tests in the org's patterns
- Compile-checked edits
- Reviewed before shipping

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

Every proposal containing Apex runs a test coverage check. If it carries its own tests, Salesforce runs those 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. The check warns before deploy day.

- Coverage checked on every proposal
- Both Salesforce paths explained
- Warned before deploy day

## How do you make coverage planned work?

Turn coverage findings into work items on a project board, with their effort, so raising coverage happens steadily between releases. A component can be proposed together with its Apex controller and its test as one change.

- Findings to work items
- Steady progress
- Class and test together

## What makes an Apex test worth keeping?

A test that checks behaviour: it sets up data, runs the code and asserts the result, including the failure cases. Tests that only execute lines raise the percentage without protecting anything, and they break the first time someone refactors.

Review generated tests the way you would review a colleague's: check that each asserts something meaningful about the class it covers before it ships.

- Assert behaviour, not lines
- Cover failure cases
- Review before shipping

## How to raise Apex coverage

1. **Measure.** Run tests and refresh for a current figure.
2. **Prioritise.** Start with flagged, severe classes.
3. **Write.** Generate tests in the org's patterns and review them.
4. **Check.** Read the coverage check on the proposal.
5. **Ship.** Validate, approve and deploy.

## Apex coverage, rushed versus planned

| Without | With SyncOnAI 360 |
|---|---|
| Coverage failure in the release window | Warned on the proposal |
| Tests that only execute lines | Tests in the org's patterns, reviewed |
| Old or missing figures | Last run shown, or Not recorded |
| No priority | Severity and effort per class |

## Apex coverage checklist

- [ ] Run the org's tests and refresh so the coverage figure is current.
- [ ] List the classes the audit flags for missing or weak tests.
- [ ] Start with severe, quick items rather than the overall percentage.
- [ ] Make sure each new test asserts behaviour, including failure cases.
- [ ] Propose each class with its test as one change where possible.
- [ ] Read the coverage check on the proposal before deploy day.
- [ ] Turn the remaining gaps into planned work items.

## Who raises coverage

- **Salesforce developers.** Write meaningful tests faster and stop release-day scrambles.
- **Release managers.** Know before deploy day whether a change will pass.
- **Consultancies.** Turn coverage gaps into scoped, priced work.

## Frequently asked questions

### What coverage does Salesforce require?

75% to deploy Apex to production.

### Why does it say Not recorded?

No test run is recorded for the org. Run the tests and refresh.

### Can it run our tests?

Yes. Ask the chat to run them, then refresh the org.

### Can AI write the tests?

Yes, around the org's own patterns. Review them before they ship.

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

Every proposal with Apex runs a coverage check that warns before deploy day.

### Does it flag code-quality issues?

Yes, such as SOQL in loops and hardcoded ids, each opened to the source lines.

### Can tests ship with the class?

Yes. A class or component can be proposed with its test as one change.

### Is this on every plan?

Yes. Every plan includes every feature.

### Does coverage show per class?

Coverage comes from the org's last test run, and the audit flags classes with missing or weak tests.