3 个回答
Hi ShashikantNo, 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 ;)
