What is the best strategy for testing in Salesforce?
Firstly, Many developers don’t distinguish between a unit test and an integration test. In a unit test, you are only focused on a single module or method, whereas in an integration test you are testing a bunch of modules combined. A very common strategy used by developers is to test the whole functionality without wanting to test the whole piece. In most cases, this might be ok 😕😕. Then what is the problem or why do you need a strategy for writing tests?
In organizations where business is tightly coupled around few objects or there are a ton of trigger calls that needs to happen, A very common error that occurs is Error: System.LimitException: Too many SOQL queries: 101
As soon as, Too many SOQL queries: 101 is seen the developer starts thinking of a SOQL in for loop. That’s a common root cause. However, not every time. You might have followed all the best practices and still see this error. It’s not you. The root cause is the nature of the business, Sadly you can’t do much there. At the same time, you can’t suppress the tests either.
Assume there are 20 SOQL calls that happen on Updating the Case (accounting for all the trigger calls, flows, etc). A Case has some child records and they in turn lead to few more calls and you genuinely hit more than 200 calls for the whole test setup. This might seem unrealistic — But, I have faced it not once but several times. Now, You might think why not use Test.startTest() and Test.stopTest() which increases the SOQL limits to 200 and other governor limits. This is a time bomb, and you just increased the timer.
Here’s one way to solve this crisis. Roll your sleeves, from here this is purely technical and Apex.
Scenario: Assume you have two trigger classes. CaseTriggerHelper, AccountTriggerHelper. They each have methodOne, methodTwo, methodThree methods respectively. There are two test classes, CaseTriggerHelperTest and AccountTriggerHelperTest. Let me show you, what I mean.
The test classes and the helper classes show the pattern above. It’s easily extendable and the only drawback of this approach is — Developer is assumed to have better knowledge of business and code. He/She has to know which methods are being tested and figure out the methods to include and exclude. It’s a one-time investment and the dividends are paid handsomely.