In one of our lasts dev retrospectives, we started a discussion about how annoying, and sometimes boring, writing unit tests can be. Not because of the tests themselves, but because of how repetitive it can be. And how different tests can look depending on who was working in those tests.
And yes, because most of the times you end up with a never-ending class packed with many methods where the only difference are a couple of values and with a ton of lines just for data generation.
And as we were pretty sure about we are not the only developers with the same thinking, we decided to invest time to find out a viable solution.
Thanks to the mighty Google DuckDuckGo, I bumped into a couple of really interesting resources in my haunt for The Test Framework.
The first resource I want to recommend is this blog. Read it, seriously, READ IT. It’s a quick and revealing post where @matpryce talks about his experience when dealing with different test data builders.
After reading Mat’s blog I could only think that applying the Builder Pattern would be a good approach to the problem we discussed in the dev retrospective.
The Builder Pattern copes well with data variation, it makes your tests easier to be written and read by externalizing the generation of data from your classes, and it gives you an easy way to create test data (even easier if your test method does not care about values) among other benefits.
Test class before and after applying Apex Domain Builder
But theory always sounds good, and developers tempt to try to apply every single new pattern we learn. So I decided to keep investigating and try to find someone who applied this to Salesforce. This was how I found this git repository by Robert Sösemann.
Robert’s git is excellent. He even adds the fflib_SObjectUnitOfWork to twist a bit more the Builder Pattern in order to create a test framework more suitable with Salesforce.
I spent some time giving it a try and my conclusion is that both, the Builder Pattern and the APEX Domain Builder, are good solutions to the problems we all face with unit tests. You can most probably just use Robert’s solution or create your own based on the Builder Pattern.
But on the other hand, I have to say that you have to be very careful when applying patterns to your projects. There are many patterns, all with its pros and cons. And even though the Builder Pattern is plenty of pros (from my humble opinion) it has a big con, time.
The amount of time you need to invest to create all the builder classes, to ensure all the SObjects builders have the correct relationship with their parent and children builder classes and to ensure that all this code deploy and work as you expect can discard this pattern if you are dealing with a non-large project.
That’s why my main recommendation in this blog is to keep always learning and find time for POCs. It will help you to understand what you are reading and to clarify what pros and cons this new feature or technology can have.
Even more, the POC I did with the APEX Domain Builder opened a really nice conversation between the Desynit developers. It gave us ideas about how we can reduce the time needed for the creation of all those classes, and so, make the Builder Pattern applicable to small projects. Maybe with VSCode templates? With the Tooling API? With a mix of both?
We do not know yet, but we now have some more ideas to develop. Ideas that will motivate us, increase our code skills, speed up our projects and improve our customer’s experience when working with Desynit.
