Premise
I want to load Accounts and their related Contacts using Test.loadData()
and StaticResources
. How do I do this given that the Contact records must have the ID of their parent Account yet the CSV file containing the Contacts can't know in advance what the Account's ID will be?
SFDC Help KB has one solution using Cases and CaseComment and there is an Idea here.
The SFDC KB article uses legitimate ID values (18 chars) in the parent CSV's ID column and child CSV's parentId column. The child CSV parentId column must reference the same ID as used for its intended parent.
But clearly the parentId in the CSV won't be the real ID of the inserted parent SObject. So, can the ID values be arbitrary as long as they are unique?
Best Answer
And the answer appears to be yes (a tip to a colleague of mine who discovered this) and it works for master-detail relationships too
The Proof
Account
Contact
with lookup relationship AccountId and custom lookupAlternate_Account__c
Here's the CSV file for the Account - note the values of
0
and1
for the testAccount.ID
rows:And here's the CSV for the Contacts - note the values in the
AccountId
column andAlternate_Account__c
column reference the artificial IDs of Account CSV rows:Using this Apex testmethod, I loaded the Accounts data from the static resource first and then the Contacts data from its static resource. I displayed the constructed SObject relationships using System.debug:
And here are the results:
The Contacts are appropriately parented and the
Contact.alternate_account__c
lookup is also accurate.Side note - what does not work is references within a StaticResource dataset. For example, I tried to use the Contact.ReportsToId field to have one Contact be a child of another in the same batch as shown here:
This isn't surprising as the Sobjects are inserted as a batch and the intra-Sobject reference is not resolvable yet. No different than using DataLoader.
Side note 2 Another use case I couldn't get to work via this approach was loading PricebookEntry rows for the standard pricebook unless you used the actual ID of the standard
Pricebook
as you can't insert a standard pricebook via testmethods. This can have some portability issuesSummary
What is striking to me is that across Apex statement executions (the successive Test.loadData(..) lines), SFDC keeps track of a mapping between real IDs of the loaded Sobject and the fake ID you specify in the CSV file so you can build relationships. None of this is documented in the Apex Developer's Guide and the casual developer could easily assume that Test.loadData(..) can only load top level SObjects or otherwise force the developer to post-process and add the relationships later.