This is a canonical question and answer developed by the community to help address common questions. If you've been directed here, or your question has been closed as a duplicate, please look through the resources here and use them to shape more specific questions. To browse all canonical questions and answers, including more unit test resources, navigate to the canonical-qa tag.

This canonical question is intended to address several classes of common questions by providing a quick summary and links to comprehensive resources

  • When is it justified to use the annotation @IsTest SeeAllData=true?
  • Using SeeAllData=true sure makes my testing life easier, why is it recommended on this forum and elsewhere not to use it?
  • What does Test Isolation mean?


Salesforce enforces a nice discipline on developers - in order to deploy, Apex classes and triggers must demonstrate at least 75% code coverage across the code base. Code coverage is achieved by writing Unit Tests. Unit tests, properly designed, verify your logic and code paths.

For a unit test to work consistently as the code is deployed across orgs (from your sandbox/scratch org to CI orgs, to QA orgs, and finally to PROD), the test environment must be invariant to the test method. Salesforce recommends isolating Test Data from Organization Data in Unit Tests.

When you introduce SeeAllData=true into your testmethods, you are, in effect, altering the test environment as your code moves from org-to-org during your devops/deployment pipeline.

Example: A SOQL query that depends on a certain setup of Pricebooks and PricebookEntries might suddenly stop working as expected when those records are CRUD by the org users.

This might not seem like a big deal to you, the Apex hero at your org, but that environment can change over time, long after you are gone or long after you have forgotten your reliance on the setup nuances of org data that makes your tests run successfully.

What is Org Data?

  • Setup Data such as Users, Profiles, Groups, Folders, Roles, Sharing Rules, Custom Permissions, Custom Metadata, Custom Settings, etc.
  • Non-setup Data such as records for: Accounts, Opportunities, Product2s, and custom objects

Mocking Org Data

Almost all Salesforce SObjects can be mocked in a testmethod so you don't need to use SeeAllData=true. There are a variety of techniques, some easily enabled if you've adopted a design pattern.

  • Mocking by inserting SObjects using DML including Test.loadData, Test factories, TestSetup-annotated methods, and direct DML within the testmethod.
  • Mocking SObjects using new XXX(fldA='foo', fldB='bar', ...) and passing these SObjects to methods under test or by using dependency injection to have methods return these SObjects for use by other methods. A good example of this is the Selector pattern on Trailhead.
  • Mocking SObjects that don't support construction. Instead, use Json.deserialize. AsyncApexJob is a good example of this.
  • Mocking in-memory parent and child SObjects (see Third Party Testing Frameworks below)

If it seems like a lot of effort to mock up Accounts-Contacts-Opportunities-Quotes-Orders-etc (or some complex graph of custom objects), avoid falling into the SeeAllData=true trap and instead decompose your testing into pieces, verifying that each layer handles its inputs, marshals the correct arguments to supporting services and generates expected outputs. Good software architecture aids immeasurably here. One resource to consider is the Apex Enterprise Patterns Trailmix.

What about the Org Data that can't be mocked?

Some Org Data is always available to the testmethod without recourse to SeeAllData=true. For example, Folders, Profiles, StaticResources, Users. You should write your tests to be resilient so that if they require a specific Profile, that the test fails with an assert if that profile is not present.

I've mocked as much as possible, so when do I really need SeeAllData=true ?


Third-Party Testing Frameworks (Advanced Topics)

Books on Apex Testing Frameworks

  • I'm a bit leery of mentioning third party testing frameworks as it might open a bit of a can of worms. – Adrian Larson Dec 28 '18 at 1:38
  • How so, @AdrianLarson? The problem of defining relevance? – David Reed Dec 28 '18 at 1:48
  • @AdrianLarson - my two cents: Force-DI was featured at DF 18 in two sessions; ApexMocks is a natural extension to fflib which in turn is featured in TrailMix for Enterprise Patterns. I also think developers will adopt a framework with their eyes open. Skilled developers will say "this looks useful"; newbie developers will say "this looks too complicated" and avoid. – cropredy Dec 28 '18 at 2:03

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.