Apex Code Development You need to sign in to do that
Don't have an account?
Roger Wicki Optimising test classes - omit DML in tests
Hi Community
I wonder what you use as best practice for test classes. I have test methods which run really slowly because they depend on many objects which have to be in place before I start testing. Usually, I create test records within a test class and insert them which also causes all triggers on those object to run. So I wonder if there is a best practice of not using any DML in test classes & methods but instead rely on manually created records withing the test classes. I'd certainly need to simulate an ID creation as most of my code uses map<Id, sObject> containers. Also, how could I handle system and formula fields?
I just wonder if there is anyone with a similar problem who found a solution for optimising test run time.
I wonder what you use as best practice for test classes. I have test methods which run really slowly because they depend on many objects which have to be in place before I start testing. Usually, I create test records within a test class and insert them which also causes all triggers on those object to run. So I wonder if there is a best practice of not using any DML in test classes & methods but instead rely on manually created records withing the test classes. I'd certainly need to simulate an ID creation as most of my code uses map<Id, sObject> containers. Also, how could I handle system and formula fields?
I just wonder if there is anyone with a similar problem who found a solution for optimising test run time.
Could you check if your test classes having seeAllDate = false because it could be one reason to be slow.
Thanks
Shashikant
No, some of the test classes do actually need to have seeAllData = true at the moment. I am planning to refactor most of those test classes because there is new functionality available. I will have to migrate almost all Custom Settings to Custom Metadata Types because this is one of the main reasons, why I actually have problems there. I can't create thousands of records that I really need to have available in a test class for a custom setting and fetching those does need seeAllData = true. But thank you for the input, this is surely worth a try.
Another thing that I suspect to be slow is parent object recalculations. Because if I change something on a detail record in a master detail relationship, that also has roll up functionality on the parent, the parent is refreshed / recalculated on any (relevant?) change on the child. This can cause unwanted trigger recursion. I do have recursion test and prevention in place but I can not be sure at runtime, if the e.g. account update was 1) caused by a trigger handler on e.g. opportunity and 2) if there are actually calculations to be done on Account after such a change. At least for 2) it requires looping through every record at least once which causes it to be slower. I am thinking about a static String set maybe, which I might use for telling the account trigger that handler a, c and f do not need to be run through the opportunity update I just did. But this is still an idea and not yet really developed further in thought.
I'll stick with a thumbs up for now – depending on the success I'll have with this answer I'll mark it as the best answer ;)
Thanks for sharing information.
As you said this is fine for now. Please mark this post as solved so that others having same issue could be benifitted from it.
Thanks
Shashikant