Apex test isolation best practices to cut flakiness: manage external deps, use test-data factories, mock callouts & events, and reset static state consistently
## Why test isolation matters
Flaky tests slow development, mask regressions, and erode confidence in your CI pipeline. In Salesforce, test instability often stems from uncontrolled dependencies: org data, external callouts, time-sensitive logic, and persistent static state. Applying isolation best practices makes tests deterministic, fast, and maintainable.
## Core principles for isolated Apex tests
### 1. Always prefer SeeAllData=false
Use @IsTest(SeeAllData=false) for unit tests to avoid reliance on org data. Create the minimal records your test requires with test data factories or @testSetup methods. This guarantees repeatability across sandboxes and scratch orgs.
### 2. Use test data factories and @testSetup
Centralize record creation in reusable factory classes. Combine factories with @testSetup to create common baseline data once per class, then keep individual tests focused by creating only the data they need. Factories improve readability and reduce duplication.
### 3. Mock external dependencies
Replace real HTTP callouts, callouts to external systems, and integrations with mocks. Use the HttpCalloutMock interface, the Stub API, or custom dependency-injection hooks so tests exercise only the unit under test. For platform events and streaming, rely on Test.stopTest() to ensure asynchronous behavior is processed deterministically.
### 4. Control asynchronous behavior
Wrap async invocation (future, queueable, batch, platform events) within Test.startTest() and Test.stopTest() to enforce execution during tests. Avoid long-running async expectations and assert outcomes synchronously after Test.stopTest().
### 5. Reset static state and singletons
Static variables and caches persist across tests in the same transaction. Provide reset() APIs on singletons or avoid mutable statics. Use @TestSetup to reduce cross-test contamination and call explicit teardown or reset helpers where necessary.
### 6. Avoid time and locale dependencies
Replace DateTime.now(), UserInfo.getTimezone(), and locale-based logic with injectable time and locale providers for tests. Use fixed DateTime values and make time injection configurable so tests remain deterministic.
### 7. Keep tests small and focused
Each test should validate one behavior or scenario. Small tests are faster and easier to debug when they fail. Favor multiple focused tests over one large test that covers many paths.
### 8. Assert behavior, not implementation
Assert observable outcomes — records created/updated, exceptions thrown, limits consumed — rather than internal state. This makes refactoring easier and prevents brittle tests tied to implementation details.
## Quick checklist before committing tests
- @IsTest(SeeAllData=false) used by default
- Test data created via factories or @testSetup
- External callouts mocked or stubbed
- Test.startTest()/Test.stopTest() used for async
- Static state reset between tests
- Time and locale injection implemented
Conclusion
Isolated Apex tests are faster, more reliable, and easier to maintain. Apply these practices to reduce flakiness and improve team velocity. Want to generate compliant, isolated Apex tests automatically? Try Test Class Generator to produce robust test classes and test-data scaffolding tailored to your org.