This article was originally published by David Godoy, Ebury’s Salesforce Developer, in this LinkedIn profile.
You are dealing with tight deadlines for the project you have been working on for the previous months, you have the release deadline set for tomorrow, all your team of developers have been working together putting all those awesome new features in place, testing, reviewing code, etc.
Good thing is that all the new stuff is ready to be packaged together and added to the release pipeline. Everything looks good…
Until you run the unit tests, and then BOOM!
How could this happen?
You made sure to review all the code changes, there are no queries in loops and all the developers are following the awesome Salesforce best practices to build efficient Apex code. Moreover, in your last code changes you see that only 2 additional new queries were added to your business code. How could this happen?
You go a step forward and try to run the exact same test context, but without your last changes and realize the following:
You have been always so near the governor limit, but you never realized until it was too late. Now you will have to spend a lot of stressful hours, trying to refactor your old legacy code just for your awesome new features to be available at Production before the deadline arrives.
How could we avoid this?
Sometimes when you work with a very big product, it may happen that you hit the governor limits, and that doesn’t really mean that you are following bad practices while coding, or that your code is not efficient enough. It may be that your product really needs to do a lot of complex stuff.
In those situations, you will need to sit with your technical leads or product representatives, and find how to overcome this situation, analyzing the current features you have, how to improve them or even if you have to deprecate them. But that is a lot of work to do. And remember that you still have a deadline to achieve.
How can TestExtension help you here?
The TestExtension allows you to define a contract of how much your Apex code will use the governor limits of the platform.
Just to put it simple, it works in a similar way to the Apex code coverage, in which you are committed to cover a 75% of your code with tests, but in this case you would be committed to cover less than a certain X% amount of the governor limit (for example SOQL queries, if you set a 80% of coverage, your test would fail once hitting the 81th query ran).
This is as simple as setting your contract for governor limits in a Custom Metadata Type in your environment in which you are running your tests.
And change your tests to use the TestExtension, instead of the standard Test library provided by Salesforce, that way the limits you are using in your tests can be measured.
Same scenario, but with TestExtension in place
Ok, let’s go back to our project scenario, but this time we already implemented the TestExtension beforehand.
You have packaged all your awesome new features together and you try to release it, you run the Apex unit tests again, and then… BOOM!
But, what happened again? We have changed the standard Salesforce error by a custom error, how is that different for our release deadline and our capabilities for refactoring the existing code?
That may be true, but remember, with the TestExtension we have defined a contract for the governor limits we are committed to cover. And we have full control over that contract, which means that we can change it for the purpose of the deadlines we have at hand.
Remember that we defined a 80% coverage for the SOQL queries in our tests, so it would be as easy as changing that configuration and increasing that contract we defined for the tests:
So, if we run the exact same test, without changing anything else, we will be able to see that it will pass:
The good news about this is that you will be on time for your project deadline, and you will have plenty of time to do all that exhausting stuff about analyzing, deprecating, refactoring and meeting with tech and product representatives. All of that without the stressful situation you would face otherwise.
We have seen how the TestExtension allows us to define contracts for the Apex governor limits, which are completely configurable and easy to change. This allow us to have a better control of the status of our code in terms of governor limits, which are usually very difficult to measure until it’s too late to react to them.
Here you can find the URL to the project in Github, because the theory is good but it is better to see it into practice: TestExtension