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.