Using Limits, startTest and stopTest

The Limits methods return the specific limit for the particular governor, such as the number of calls of a method or the amount of heap size remaining.
There are two versions of every method: the first returns the amount of the resource that has been used in the current context, while the second version contains the word “limit” and returns the total amount of the resource that is available for that context. For example, getCallouts returns the number of callouts to an external service that have already been processed in the current context, while getLimitCallouts returns the total number of callouts available in the given context.
In addition to the Limits methods, use the startTest and stopTest methods to validate how close the code is to reaching governor limits.
The startTest method marks the point in your test code when your test actually begins. Each test method is allowed to call this method only once. All of the code before this method should be used to initialize variables, populate data structures, and so on, allowing you to set up everything you need to run your test. Any code that executes after the call to startTest and before stopTest is assigned a new set of governor limits.
The startTest method does not refresh the context of the test: it adds a context to your test. For example, if your class makes 98 SOQL queries before it calls startTest, and the first significant statement after startTest is a DML statement, the program can now make an additional 100 queries. Once stopTest is called, however, the program goes back into the original context, and can only make 2 additional SOQL queries before reaching the limit of 100.
The stopTest method marks the point in your test code when your test ends. Use this method in conjunction with the startTest method. Each test method is allowed to call this method only once. Any code that executes after the stopTestmethod is assigned the original limits that were in effect before startTest was called. All asynchronous calls made after the startTest method are collected by the system. When stopTest is executed, all asynchronous processes are run synchronously.

Best Practice while using Test.startTest & Test.stopTest in Test class:
Here are a few use cases that come to mind:

  1. Adds a new context for your test with its own set of governor limits
  2. Allows testing results of asynchronous apex. When stopTest is executed, all asynchronous processes are run synchronously.
  3. Allows you to target which code you actually want to test. Example: You want to test Update Trigger specifically so you insert your data before the startTest and then update after startTest.
  4. Allows you to test limit usage for specific code. Example: How much SOQL or DML does an update operation consume?

Comments

Post a Comment

Popular posts from this blog

Adding a red asterisk to required fields using label in LWC

Image
I am trying to add a double or single asterisk to lightning: input tags in LWC, by using "required" tag inside the tag I am able to see the asterisk, but two issues with this are I have to show a red asterisk to some conditionally mandatory issues. Solution -  You can use  label-hidden  variant and put a label. <template> <label>Middle Name</label> <abbr title="required" class="slds-required">**</abbr> <lightning-input label="Middle Name" variant="label-hidden" aria-required="true" maxlength="80"></lightning-input> </template>
Read more

The Developer Console didn't set the DEVELOPER_LOG trace flag on your user. Having an active trace flag triggers debug logging. You have 1,978 MB of the maximum 1,000 MB of debug logs. Before you can edit trace flags, delete some debug logs.

1. In developer console, Select tab "Query Editor" at the bottom of the console. 2. Select check box "Use Tooling API". 3. Execute the below query: SELECT Id FROM ApexLog   4. Select All Rows. Click the first row and then press Shift button and click last row to select all the rows. Delete all rows using Delete button. https://help.salesforce.com/articleView?id=code_debug_log_delete.htm&type=5
Read more

Troubleshoot 'System.LimitException: Batchable instance is too big' error

If a batch apex class implements Database.Stateful, the instance state is stored in the database.  At this time we do a check against the size of the instance state and t he exception is thrown when the Apex Heap Size limit is exceeded. For synchronous Apex the heap size limit is 6 MB and for asynchronous Apex the limit is 12 MB.  This exception can obviously occur in a scenario where large collections are persistently maintained. Even if some chunks fail with this error, the batch job is completed. As per below lines in  Batch Apex Developer Guide   "If the first transaction succeeds but the second fails, the database updates made in the first transaction are not rolled back." To work around this issue, you can use the following steps: 1. Avoid using Database.Stateful 2. Reduce the amount of persistent data 3. Process less records per batch   In some cases Database.Stateful isn't being implemented or the steps above are not helpful in working around this e...
Read more