System.AssertException: Assertion Failed on deploy

Why does the deploy fail when the code compiles?

A test method ran System.assertEquals (or assert, assertNotEquals) and the two values did not match. The deploy stops because Salesforce rolls back the whole deployment when a required test fails. The metadata itself is fine.

The message tells you most of what you need: your custom message if you wrote one, then Expected and Actual, then the class, method and line.

Why does the assertion fail on deploy and not in my sandbox?

• The code changed and the test did not. Someone moved a discount from 15 to 10 percent and the old assertion still expects the 15 percent number.
• The test depends on data that exists in the sandbox but not in the target. It queries an existing Account or relies on a record type Id and gets nothing back.
• The target org has automation the sandbox lacks, such as a validation rule, a flow or a trigger that changes a field the test then reads.
• The test depends on order, the current date or a sharing setting, so it passes on one day and fails on another.

What does the assertion failure look like?

A class applies a 10 percent discount. A test expects 85 from an input of 100, because the author remembered the old rate. Check-only deploy with --test-level RunSpecifiedTests:

DiscountCalcTest.tenPercentOff
System.AssertException: Assertion Failed: Expected a 15 percent discount: Expected: 85, Actual: 90.0
Class.DiscountCalcTest.tenPercentOff: line 5, column 1

The first text after "Assertion Failed:" is the message argument you passed. Always pass one. It saves ten minutes of reading code.

How do I fix it in Setup?

1. In the target org, open Setup > Deployment Status, find the failed row and click View Details. Scroll to the test failures and copy the method name and line.
2. Open the test class and read the assertion at that line. Ask one question: is the expected value still the right business answer?
3. If the code is right, update the expected value. If the code is wrong, fix the code in the sandbox and redeploy.
4. If the test reads existing data, rewrite it to create its own records. Salesforce's testing guidance is to create the data a test needs inside the test, so it does not rely on a particular org (Apex Developer Guide).
5. Run the class in the sandbox: Setup > Apex Test Execution > Select Tests > Run.

How do I fix it with the CLI?

sf apex run test --class-names DiscountCalcTest --result-format human --wait 10 -o <sandbox-alias>
sf project deploy start --dry-run --source-dir force-app --test-level RunSpecifiedTests --tests DiscountCalcTest -o <target-alias>

A test that passes in the sandbox and fails in production nearly always reads data or automation the two orgs do not share.

How do I keep assertions stable across orgs?

Run the covering tests in the sandbox on the same test level you will use in production. Write assertions with a message. Avoid SeeAllData=true, because it ties the test to whatever happens to be in the org that day.

Once a validation passes, a quick deploy can skip the test run on the real deploy, within 10 days of a validation that ran the tests (Metadata API Developer Guide). Do not touch the org between validate and deploy if you plan to use it.

Clientell AI runs the covering tests before you approve and prints the line and reason for each failure. See AI Salesforce deployments.

Other test-time failures: coverage below 75%, trigger exception, validation rule in a test, callout in a test.