Matthew Botos
Technical Archtiect

Innovative and Mobile Architect, creator of 2nd Opinion iPhone app, and author of open source Toolkit for Google Analytics. Avid photographer, snowboarder, and mountain biker.

Read Posts  
Using the right data in your tests can be tricky, but this post will take you through a quick evolution and share our best practices for test data.<br><br>Let&#39;s start by simply grabbing some existing data for our test:<br><pre class="brush:apex"> <pre> Contact c = [select Id from Contact where Id = &#39;123&#39;]; </pre> </pre> <br>When that blows up in a different org, we make it a little more flexible:<br><pre class="brush:apex"> <pre> Contact c = [select Id from Contact limit 1]; </pre> </pre> <br>That works until we deploy to an empty org, like a configuration-only sandbox. At this point, we realize we should really be creating unique test data from scratch. Since test contexts always rollback all data, we can do this freely without worrying about polluting any real data in production:<br><pre class="brush:apex"> <pre> Contact c = new Contact(LastName = &#39;Botos&#39;); insert c; </pre> </pre><br>Now our test data works in any org! We just had to remember what fields were required on Contact, and could add additional fields that might be used in our test.<br><br>In the real world, though, we&#39;re often jumping into new orgs with unknown required fields and relationships. What if our org&#39;s Contact required a lookup to a custom object Client__c, which it turn required field Industry__c? After a bit of digging and trial and error, we come up with:<br><pre class="brush:apex"> <pre> Client__c client = new Client__c(Industry__c = &#39;Life Sciences&#39;); insert client; Contact c = new Contact(LastName = &#39;Botos&#39;, Client__c = client.Id); insert c;</pre> </pre><br>Whew - that&#39;s going to be a real pain as we get into complex orgs! I had the same thought, and tackled the problem during our May 2011 Mavens Hackathon with <a target="_blank" href="">SmartFactory</a>. SmartFactory is a native library that uses Salesforce&#39;s own metadata describe methods to understand the structure of your objects and automatically create test data:<br><pre class="brush:apex"> <pre> Contact c = (Contact)SmartFactory.createSObject(&#39;Contact&#39;, true);</pre> </pre><br>The second argument toggles the cascade option, which populates any lookup fields on the object with their own newly created objects. It&#39;s a powerful way to create hierarchies of test data quickly and easily so you can focus on writing test and implementation logic.<br><br><a target="_blank" href="">SmartFactory</a> is part of the open source collection Mavens has released on GitHub; you&#39;re free to use it in your projects and contribute any additions you find useful.<br><br>This is by no means the last chapter in the evolution of test data; I look forward to hearing your own thoughts and best practices below!