I have experienced a bunch of test classes fail to pass in a Sandbox, but execute fine in Production.

Has anyone some good tips on what look out specifically? I think the code itself is not particularly of interest as I have almost 15 unit tests that present this error. All of them possess different logics.

Note I keep on getting the error even when I run the tests individually or in a group.

  • 1
    You'll want to enable Profiling to determine the cause, and read the logs after running tests. – sfdcfox Aug 6 '19 at 16:01
  • What do you exactly mean with Profiling? – Endrit Sino Aug 6 '19 at 16:09
  • Are you using seeAllData as true in your test class? Or any package which is installed just in prod but not in sandbox? – Pranay Jaiswal Aug 6 '19 at 16:16
  • 1
    See this article as an example of profiling (Developer Blog post). – sfdcfox Aug 6 '19 at 16:20
  • 1. Debug logs are your friend. Read them. 2. @isTest(seeAllData = false) annotation on test class and methods is your another friend. – Walker Aug 6 '19 at 16:57

Here's what I would check:

  1. If the tests are (@seeAllData= true)... if this is the case, you need to make your soql queries more selective
  2. Are you using a testdatafactory? if so, check if someone messed it up recently
  3. See if there's code that's recursively called, and should not be. So for example, do you have account updating all the contacts, which is updating the account, etc? If this is the case, you need to block the recursion.
  4. Are you referencing global classes/ methods that are part of a managed package? The WSDL in Salesforce that you have in SF might be out of date (this is rare, but happens with products like Zoura..)
  5. Check out profiling if all else fails - https://developer.salesforce.com/blogs/2014/05/a-guide-to-application-performance-profiling-in-force-com.html
| improve this answer | |
  • Points 1. is ruled out. Point 2. is a bit unclear what would this imply, as if it messed up, then it should be messed up in Production too. Am currently planning to be even more careful and debugging granurarly, following your and @sfdcfox's suggestion. Thanks for point 4., that maybe opens up a broader perspective. – Endrit Sino Aug 9 '19 at 8:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.