Test data creation in Salesforce using Builder Pattern

Delegate the instantiation of your sObjects to a more standardized class to get more control over your test data.

The Builder Pattern is a software design pattern intended to add more abstraction to the instantiation of Objects, where you can preset certain steps of the process simply by, setting some properties with default values coherent with the context of the execution.

Builder Pattern Diagram, Director is our Test Method

Basic diagram of a Builder Pattern. The Director in this case, is the Test Method.

Say you have a Custom Object with several required fields, but you need to test a method that only needs a few of them, wouldn’t it be easier to create it by calling something like:

Custom_Object__c example = new TestDataFactory.CustomObjectBuilder.build();

Instead of:


So, first of all, what is TestDataFactory? And where does it come from?

Essentially, TestDataFactory, is the Builder (remember? The one in the title). It contains the methods that will encapsulate the constructors of all the classes we’ll need during our tests.

At this point we have a couple of clues of how this upper class should look like: It’s a class (duh) and it’s going to be used for our tests:

Well, that’s a start.

The @isTest annotation implies that the class won’t count to the org’s code limit, and will also be executed exclusively by Test Methods.

Now we need the class to do something. This is the fun part.

Inside the class, we’ll need subclasses to handle each individual object we want it to instantiate. Those classes should have the necessary settings to cope with their object’s demands and also be easy to handle at the time to create a Test Method.

Let’s work with a Person__c:


Here’s the basic structure of the Builder, a class with several private attributes (all Strings, how convenient) and a constructor method.

The idea is to reflect all the sObject’s properties we need as private properties and set the ones required with dummy data just to not do it later.

Looks like a wrapper? It’s kinda like a wrapper.

We’re only two steps away from getting this working:

  1. Customize (set) the values for all the attributes, and

  2. Create the actual object

To set the attributes we’ll use (drumroll…) a setter method with a little twist: the return of the object (this, for family and friends)

One of those for each attribute.

Next, the instance, the build() method:


As we can see, the Name and LastName fields are set with the classes’ private attributes, and will keep their default values if the setting methods are not called, and finally returning an instance of Person__c

To wrap it up:

And finally, the call from a Test (ideally inside a @testSetup method):


And that’s it, we now have a Person object named Sample Doe, who studied in Some School.

This creates objects in the same way and with the same default data every time, helping with the testing process and resulting in much clearer code.


Posted in:

Leave a Reply

Your email address will not be published. Required fields are marked *