03.02.04 — Why Test Cases Fail in Real Projects (and How to Fix Them)
Lesson goal
This lesson explains why test cases that look correct on paper fail in real Salesforce projects and how to recognize and fix the root causes.
After this lesson, you should be able to:
- identify failure patterns early,
- understand why “good” test cases still produce bad results,
- improve test design before execution begins.
Why test cases fail outside theory
Most failed test cases are not poorly written.
They are written in isolation from real project constraints.
In Salesforce projects, failure often comes from:
- incomplete context,
- hidden assumptions,
- organizational shortcuts.
Understanding these patterns is more valuable than learning new formats.
Failure pattern 1: The author knows too much
The author unconsciously fills gaps:
- missing Preconditions,
- unclear steps,
- vague Expected Results.
The test works only for the person who wrote it.
Fix
- perform Dry Runs with a different executor,
- treat confusion as a defect,
- rewrite test cases based on execution feedback.
Failure pattern 2: Environment-dependent assumptions
Test cases assume:
- specific data already exists,
- certain users are configured,
- permissions are “standard”.
After sandbox refresh or deployment, these assumptions break.
Fix
- define all required data and permissions explicitly,
- avoid references to environment-specific artifacts,
- treat Preconditions as a contract, not a suggestion.
Failure pattern 3: UI-driven instructions
Steps are written as click paths:
- buttons,
- tabs,
- Lightning components.
When UI changes:
- steps break,
- testers improvise,
- execution becomes inconsistent.
Fix
- write functional instructions,
- rely on Preconditions for context,
- verify behavior, not navigation.
Failure pattern 4: Overloaded test cases
A single test case tries to verify:
- permissions,
- validation rules,
- automation,
- integrations.
When it fails, no one knows why.
Fix
- split test cases by intent,
- keep one primary verification goal per test,
- isolate failures.
Failure pattern 5: Vague Expected Results
Expected Results confirm:
- that something happened,
- but not that it happened correctly.
This allows defects to pass unnoticed.
Fix
- verify business logic, not UI reactions,
- use one verification per step,
- confirm both action and non-action where relevant.
Failure pattern 6: Skipping negative paths
Only happy paths are tested.
Validation and permission issues appear late:
- during UAT,
- after release.
Fix
- identify negative paths during analysis,
- design explicit tests for enforcement,
- prioritize error handling tests.
Failure pattern 7: No ownership of test quality
Test cases are written, but:
- not reviewed,
- not improved,
- not treated as assets.
Quality decays over time.
Fix
- apply review models consistently,
- treat test cases like code,
- refactor documentation when behavior changes.
Key takeaway
Test cases fail not because of formatting errors, but because of design blind spots.
The fastest way to improve Salesforce test quality is:
- recognizing common failure patterns,
- fixing them before execution,
- embedding feedback loops into test design.
Strong test cases are designed for reality, not theory.