03.02.03 — Expected Results: What to Verify and What to Ignore
Lesson goal
This lesson explains how to define Expected Results that actually validate Salesforce behavior instead of confirming obvious UI reactions.
After this lesson, you should be able to:
- distinguish meaningful verification from superficial checks,
- define Expected Results that validate business logic,
- avoid common mistakes that reduce test value and confidence.
---
Why Expected Results are often the weakest part of test cases
In many Salesforce projects, Expected Results are treated as a formality.
Typical examples include:
- “Record is saved successfully”
- “User sees an error message”
- “System behaves as expected”
These statements provide no real verification.
Expected Results should prove that the system behaved correctly, not that something happened.
---
The purpose of Expected Results
Expected Results answer one question:
What exactly must be true after this step for the test to pass?
They define:
- observable system behavior,
- business rule enforcement,
- data state changes.
Expected Results are not summaries.
They are verification checkpoints.
---
One verification per step
A core rule:
One step = one Expected Result = one condition to verify
Violating this rule leads to:
- unclear failures,
- partial passes,
- inconsistent execution results.
Example
Poor:
Opportunity is saved and approval is triggered
Better:
- Step: Save the Opportunity
- Expected Result: Opportunity is saved in Stage = Closed Won
- Step: Submit Opportunity for approval
- Expected Result: Approval request is created and assigned to the correct approver
This separation makes failures diagnosable.
---
Verifying business logic vs UI behavior
UI behavior is rarely the primary value in Salesforce testing.
Examples of weak verification:
- checking that a field is visible,
- confirming that a button appears,
- verifying that a toast message is shown.
Examples of strong verification:
- confirming that a record state changed correctly,
- verifying that automation executed or did not execute,
- validating that permissions were enforced.
UI checks should support logic validation, not replace it.
---
Avoiding obvious verification
Expected Results should not restate what the step already implies.
Poor:
Step: Click Save
Expected Result: Record is saved
Better:
Expected Result: Record is saved and validation rules are evaluated based on current data state
The second version forces you to think about what actually matters.
---
Handling error conditions
Error handling is a critical part of Salesforce testing.
Expected Results for errors should:
- specify why the error appears,
- confirm that business rules are enforced,
- avoid relying solely on message text.
Example:
- Not: “Error message is displayed”
- But: “System prevents save because mandatory field X is missing for this record type”
Message text may change.
Behavior should not.
---
Verifying what did NOT happen
Some of the most important Expected Results confirm absence of behavior.
Examples:
- automation does not trigger,
- field value is not changed,
- integration call is not executed,
- record state remains unchanged.
Negative verification is often more valuable than positive confirmation.
---
Avoiding technical overreach
Expected Results should verify behavior, not implementation details.
Avoid:
- referencing Apex classes,
- assuming internal execution order,
- validating logs or debug output.
Those checks belong to technical testing, not functional test cases.
---
Expected Results and maintenance cost
Well-written Expected Results:
- survive UI changes,
- remain valid after refactoring,
- reduce false failures.
Poor Expected Results:
- break frequently,
- cause rework,
- lower trust in test documentation.
In Salesforce projects, maintenance cost is often driven by weak verification, not weak steps.
---
Key takeaway
- Expected Results define what correctness means.
- They must validate business logic, not UI reactions.
- One step should have one clear verification point.
- Verifying what does not happen is often as important as verifying what does.
Strong Expected Results turn test cases into reliable quality gates.