How does Apex test data isolation work?

Test data isolation: Apex tests don't see existing org data by default. Each test starts with a clean slate.

apex @isTest private class MyTest { @isTest static void testSomething() { // [SELECT Id FROM Account] returns 0 even if production has 1000 } }

Why:

• Tests should be deterministic.
• Tests should not depend on org-specific data.
• Predictable across environments (dev, sandbox, production).

`@TestSetup` for shared data:

apex @TestSetup static void setup() { Account a = new Account(Name='Test'); insert a; }

Runs once per class; data available to all test methods; rolled back at end.

Disable isolation:

@isTest(SeeAllData=true) — sees real org data.

Strongly discouraged. Tests then depend on data that changes; flaky.

When SeeAllData=true might be needed:

• Legacy code that's hard to refactor.
• Standard objects with data — Profiles, Permission Sets are referenced even with SeeAllData=false (always visible).
• Specific Salesforce features that don't honor isolation.

Bypass: build all data in test:

`apex @isTest static void testCorrectly() { Account a = new Account(Name='Test'); insert a;

Contact c = new Contact(LastName='Test', AccountId=a.Id); insert c;

// Now test } `

Test data factory pattern:

apex public class TestDataFactory { public static Account createAccount(String name) { Account a = new Account(Name=name); insert a; return a; } }

Reusable; reduces boilerplate.

Common pitfalls:

• `SeeAllData=true` — fragile tests.
• Hardcoded IDs — tests work in dev, fail in another org.
• Order-dependent tests — pass run together, fail in isolation.

Senior QA insight: isolation makes tests durable. Invest in factories; avoid SeeAllData=true.

The senior framing: tests should describe expected behavior independent of environment. Isolation enables that.