Salesforce will let you deploy Apex at 75% coverage.
AI will help you get there with tests that insert a record, run the method, and write Apex test assertions that only prove a record exists.
Congratulations. You have coverage. You do not have tests.
A real test fails when the behavior is wrong. It checks sharing. It checks the bulk path. It checks the error the user will actually see.
Apex code coverage is a gate. Assertions are the point.
How AI Fakes Apex Test Assertions
The model is trying to be helpful. You asked for tests. Salesforce asked for 75%. The shortest path that satisfies both is a happy-path test class:
– Insert an Account, or a custom object, as the running user
– Call the method
– `System.assertNotEquals(null, result)` or `System.assertEquals(1, [SELECT COUNT() FROM …])`
– Move on
That class compiles. It runs. It moves the coverage number. It will not catch the SOQL-in-a-loop that only appears at two hundred records. It will not catch the record the community user should not see. It will not catch the error message that says “Script-thrown exception” because nobody wrote one.
Finish Score splits the testing dimension 12 points for coverage and 8 points for the quality of Apex test assertions for this reason. A suite that is at 82% and asserts nothing is not “ahead” of a suite that is at 76% and fails when sharing is wrong.
What we require in a Finish Sprint
Finish Sprint takes coverage to 85%+ with assertions that mean something.
That is one of the dullest sentences in this series and one of the expensive ones if you skip it.
Concretely, the test suite we will put in the repo does some combination of the following, scoped to what the app actually does:
– Bulk inserts and updates, not single-record happy paths
– Running-user changes — standard user, not only sysadmin
– Negative cases: the thing that should not be allowed
– Meaningful error paths, not a swallowed `catch (Exception e)`
– Apex test assertions (System.assert / the Assert class) tied to the business rule, not to “a row exists”
We do not sell 100% coverage as a virtue. We sell tests that would embarrass the code if the code were wrong.
Documentation the model never writes
Ask a team why a rescue costs what it costs.
It is rarely the trigger.
It is that nobody can tell you why the trigger exists.
AI-generated Salesforce apps arrive with comments that restate the method name and a README that says “run this.” They do not arrive with the decisions:
– Why this object and not that one
– Which Flow is load-bearing
– What happens if you turn off the named credential
– Which of the three automations on Opportunity is the real one
– What a new admin should not touch
Documentation is 10 points on Finish Score on purpose. It does not make the app safe. It makes the next human cheaper.
We write the docs the model skipped. That is part of the Sprint, not an add-on speech.
Citizen developers: keep framing. Just do not make your future self reverse-engineer the frame.
The pair that shows up together
Weak Apex test assertions and missing docs travel as a pair because they come from the same habit: stop at “it works when I run it.”
If you cannot tell a new teammate why the automation exists, you also cannot tell a test class what to fail on.
If the only person who can demo the app is the person who prompted it into existence, you do not have a system. You have a Saturday. For more on incomplete apps, check out this previous article, The 60% App.
“We will clean it up later”
Later is when the builder takes a new job.
Later is when the volume hits.
Later is when you decide this should have been a product.
Cleanup is a Sprint. Waiting is a Watch you never bought.
If “later” has been on the backlog for 90 days, it is not a later. It is the product.
What to do this week
If your current test class makes you a little proud and a little suspicious, that is the Audit.
Finish Audit is $4,500, five to seven days. You get a Finish Score, a keep / refactor / rebuild verdict, and a fixed-price quote. The fee credits toward the Sprint if you book in 30 days.
Dream it. Frame it. Let an expert finish it.
FAQ
**Is 75% coverage enough to deploy?**
It is enough for Salesforce to allow the deployment. It is not enough to know the behavior is correct.
**What makes good Apex test assertions?**
Whether the test fails when the business rule is broken, not only when the method throws.
**What are Apex test class best practices?**
Test bulk paths and single records, run as a non-admin user, cover the negative cases, and use assertions that prove the business rule. Salesforce’s own testing guidance says to use the Assert class to prove the code behaves properly and not to chase the coverage percentage.
**Do you rewrite the whole suite?**
Only the parts that do not prove anything. Happy-path coverage that already asserts the right rule stays.
**Are docs really in scope for a Sprint?**
Yes. Decision docs, not comments that repeat the method name.
Email john@cloudfirstlabs.com with “Finish Score” in the subject, or book a 20-minute Finish Audit call from the Finish page.
Built with AI. Finished by engineers.
About CloudFirst Finish
CloudFirst Finish takes a 20–90% built Salesforce app — Apex, LWC, Flow — and makes it documented, tested, and deployable. Finish Audit is $4,500 and five to seven days: a 0–100 Finish Score and a keep / refactor / rebuild verdict. Sprint, AppExchange packaging, and Watch sit behind that score. Prices and the ladder live on cloudfirstlabs.com/finish.
About CloudFirst Labs
CloudFirst Labs is a Tampa Salesforce consulting and AppExchange partner. The same bench that finishes AI-started apps is the bench that connects the Salesforce CRM, PSA, and billing systems MSPs run every day — ConnectWise, Autotask, ServiceNow, NetSuite, Certinia — so closed deals flow into delivery and invoices match what was sold. Co-founded by a former VP of Technology at a $200M MSP. We have lived the integration problems we still solve. Finish is the last 40% of an app. The MSP practice is the revenue engine those apps sit inside. Different jobs. Same production standard.
Need the MSP lane instead? Book an MSP Revenue Assessment.
Connect with John Dionne on LinkedIn and follow CloudFirst Labs for Finish and MSP systems writing, or browse more on the CloudFirst Labs blog.