Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
Do the governor limits refresh for each testMethod or we just get specific governor limits for each test class (for instance - SOQL limits 100+100 for test.start/stop)?
Please don't tag best practices to avoid SOQL 101 in test classes to this post, I am aware about those.
Yes, they reset for each method and even within startTest and stopTest calls. Keep in mind that limits in a testsetup method are aggregated with limits outside of the startTest and stopTest calls, so you in effect have 2 sets of limits for each test.
You can get information about how test methods work here
Sfdcfox (who else) has a more comprehensive answer here
When you run a unit test, Test.startTest() "sets aside" the testing governor limits, and creates a new set of limits based on the next line of execution. For example, if the next line of code is a DML operation, it sets up a normal trigger execution governor limit, while if it's a Database.exectuteBatch method, it sets the governor limits to the Batchable limits instead.
So, you should definitely see two sets of limits, the former for the queries run outside of Test.startTest() and Test.stopTest(), and those inside. It's possible that since you didn't actually "do" anything inside the actual test phase, you may have caused some sort of bug, but ordinarily, you'd expect to see 99 "outside" queries and 1 "inside" query.
Calling Test.startTest() doesn't "wipe out" the other limits, it only temporarily suspends them.
It's a little more complicated than just saying you have a limit of, say, 100 queries. You have two governor limits. The moment a unit test starts, you have your testing governor limits. They are always the same as synchronous governor limits (e.g. 10,000 ms CPU, 6,000,000 bytes heap, 100 queries, etc).
When you call Test.startTest, those limits are suspended, and the very next statement you execute after that will set new governor limits. This may be synchronous limits (e.g. you call a controller), or it might be asynchronous limits (e.g. because you called System.enqueueJob). This is further compounded by the fact that you may have installed packages, which each also have their own limits (except for some shared limits, like CPU).
Once you call Test.stopTest, the limits that were used after Test.startTest are discarded, and the suspended limits become active once again. If you used 20 queries before Test.startTest, then you now have 80 queries remaining.
There's one wrinkle to this, though. If you use @testSetup, then those limits are used as part of the testing limits. For example, if you use 5 queries in a @testSetup method, then each unit test will be limited to only 95 additional queries. In order to avoid this behavior, it is imperative that you use Test.startTest at the beginning of your @testSetup method.
Each unit test is a separate transaction, and does get its own set of governor limits. This lets you have, for example, 100 unit tests in a class that each perform 100 queries (10,000 total queries!).
You'll want to do some profiling so you can optimize your organization's transactions, as failures in unit tests are often canaries in a coalmine. You should not assume that it's just the test is poorly written.
Yes. They reset for each method. However you can also use test.startTest() and test.StopTest() in your test method to reset the governor limit. Whatever put inside this mehtods will have a fresh set of governor limits
