03.01.04 — Defining Test Data and Record State
Lesson goal
This lesson explains how to define test data and record state correctly in Salesforce test cases, and why weak data definitions are a primary cause of failed executions and false defects.
After this lesson, you should understand:
- why “existing data” is not a valid test precondition,
- how record state controls Salesforce behaviour,
- How to describe test data in a way that supports repeatable execution.
Why test data definition is critical in Salesforce
Salesforce behaviour is data-driven.
Validation rules, automation, permissions, and integrations all depend on:
- record existence,
- relationships between records,
- field values and statuses.
If test data is not defined precisely, execution becomes guesswork.
“Data exists” is not a precondition
One of the most common mistakes in test cases is relying on vague data statements.
Examples:
- “Account exists”
- “Opportunity already created”
- “Use any available record”
These statements obscure assumptions and lead to inconsistent execution.
A test case that relies on undefined data is not executable.
Test data describes structure, not creation steps
Preconditions should define what must exist, not how it was created.
Avoid:
- UI-based creation steps,
- navigation instructions,
- setup workflows inside test cases.
Preconditions describe the required data state, not the setup process.
Defining record structure
Effective test data definitions include:
- object type,
- required relationships,
- key field values,
- relevant statuses.
Example of a weak definition:
Opportunity exists
Example of a strong definition:
Opportunity related to an existing Account, Stage = Qualification, Close Date in the future
The second version defines structure and state.
Record state as a behaviour driver
In Salesforce, record state controls:
- available actions,
- validation enforcement,
- automation execution,
- record locking.
States are often represented by:
- picklist values,
- boolean flags,
- lifecycle fields.
Test cases must explicitly specify the required state.
Relationships matter more than volume
Salesforce logic frequently depends on relationships:
- parent-child records,
- lookup references,
- master-detail hierarchies.
The presence or absence of related records often determines behaviour.
Test data definitions should describe:
- required related records,
- their state,
- their role in the logic under test.
Avoiding hidden dependencies
Hidden dependencies arise when:
- test cases rely on org-specific data,
- naming conventions are assumed,
- previous test executions leave residue.
Good test data definitions:
- are minimal,
- are explicit,
- do not rely on side effects.
Each test case should be self-contained.
Data definitions and Dry Runs
Weak data definitions are exposed immediately during Dry Runs.
Common Dry Run failures include:
- missing required relationships,
- incorrect record ownership,
- incorrect initial state.
If a test fails during Dry Run, the problem is almost always in the Preconditions.
Test data vs test steps
A common anti-pattern is mixing data setup into execution steps.
This:
- duplicates effort,
- hides assumptions,
- complicates execution.
Preconditions define data.
Steps validate behaviour.
Mixing the two reduces clarity and test quality.
Common test data anti-patterns
Frequent issues include:
- using production-like data without control,
- relying on “standard” records,
- omitting state details,
- assuming default values.
Each of these increases test fragility.
Key takeaway
- Data and record state drive Salesforce behaviour.
- Vague data definitions invalidate test cases.
- Preconditions should describe structure and state, not creation.
- Strong data definitions enable repeatable, reliable execution.
If test data is not clearly defined, test results cannot be trusted.