Stress Testing Your Salesforce Code: Why, When & How

Posted by Daniel Pulache
Stress test saleaforce code blog image-01-1.png

There is only so much one can do when testing code in When it comes to testing code, there are manual tests, unit tests, and bulk tests. The importance of each test comes down to the specific scenario the code is covering. Regardless of what scenario one is testing, the code should always be bulkified. This blog emphasis on the importance of bulk testing, rather I would call it stress testing, and how to do it. 

Let’s briefly cover other types of testing:

  • Manual testing consists of testing the system manually through the UI, that includes visiting the Visualforce page, inserting or updating the record and expecting the desired result pop-up in the screen.
  • Unit testing are apex methods annotated by the @isTest which test specific scenarios of the code, ending with a final assert() comparing the expected and actual result programmatically. The limitation with this is that it is all executed in one transaction thus preventing the developer from truly stress testing the code to its limit.

Why should you stress test?

Stress testing is running the code against more than 50,000 entries. Why 50,000? One reason I believe stress testing should be performed with more than 50,000 records is because the Data Import Wizard limits you to 50,000 records. Salesforce probably choose that limit because Governor Limits can be more easily exceeded with that number of records. Examples of such scenarios are mass inserts, updates, and deletes of records.

Another reason is because transactions can behave differently, or not as expected, when importing a large set of records. Finding these discrepancies can be difficult but stress testing can be useful tool for this task plus knowing the code won’t break when mass importing records can never hurt.

While stress testing my own code, I’ve come across various errors that I would not have caught such as hitting governor limits, recursive trigger execution, and unknown (but documented) functionality of salesforce tools. For example, not hitting a governor limit in one transaction does not mean it won’t be hit in the remaining transactions. The number of records return by querying a large set of related records based on the incoming records can be a way of hitting a governor limit the code was not prepared to handle.

Recursive trigger execution can be caught when dealing with a large data set so keep track of how many times your apex triggers are firing. Unknown salesforce functionality has gotten the best of me, perhaps it’s the fact that I assume the system will work one way or remember old outdated functionality, whatever the case is, reading the documentation will save hours of programming and testing. These flaws became apparent when stress testing revealed the weak points my code. If you’re familiar with governor limits, then you’ve seen Figure 1 at the end of any log.


stress testing 1.png
Figure 1. Governor Limits

When should you stress test?

Any code that is meant to handle large sets of data should be stress tested like apex classes that use the batchable interface. Any triggers, whether it’d be insert, update, or delete, should be stress tested. One doesn’t know when the user will import a file updating more than 75k Accounts. Visualforce pages that displays sets of records and update them should also be stress tested.


Two ways to stress test gives you two tools for stress testing. One of them is the Data Loader, which you can download straight from the setup menu, and the other is programmatic tool Test.loadData(). The main screen of the data loader can be found on Figure 2.

stress testing 2.png
Figure 2: Data Loader

How you should stress test

Let’s start with stress testing your code the manual way. One can use the Data Loader,, or any other import tool that will allow 50k+ records to be imported at once. The next section will cover how to use the Data Loader as the chosen tool.

Data Loader:
  • Download Data Loader from SFDC setup menu
    • Type ‘Data Loader’ in the quick find
  • Have username, password, and security token from a system admin ready (Refer to figure 3)
  • Have CSV file ready
    • Preferably with the column header matching their respective field labels
    • 50k+ records in the CSV file with dummy data
  • Open up Data Loader
  • Connect to salesforce instance
  • Select the Object to insert/update/delete (Refer to figure 4)
  • Pick the CSV file
  • Match the column header with fields in your object (Refer to figure 5)
  • Load the file
  • Prepare the Developer Console ready to monitor each transaction as it occurs (Refer to figure 6)
  • Verify your code worked as expected

stress testing salesforce 3.png
Figure 3: Data Loader credential input


Stress testing Salesforce 4.png
Figure 4: Select object to modify

Stress testing Salesforce 5.png
Figure 5: Match Column headers with fields

Stress testing Salesforce 6.png
Figure 6: Developer Console monitoring transactions



Loading test data using Test.loadData() method:

Stress testing the code can also be done programmatically. Salesforce allows you to use CSV files, as static resources, from the database to import in bulk. This section will cover how to use the Test.loadData() method to stress test the code.

  • Have CSV file ready
    • Preferably with the column header matching their respective field labels
    • 50k+ records in the CSV file with dummy data
  • In salesforce, upload the CSV file as a static resource with .csv extension. In this example, name it ‘myResource’.
  • Begin writing the test class method
    • USE: List<sObject> ls = Test.loadData(Account.sObjectType, ‘testAccounts’);
    • TO: Load the data found inside the static resource ‘testAccounts.csv’ (Refer to figure 7)
    • ASSERT: the expected result vs actual result and verify the code worked as expected

Stress testing Salesforce 7.png
Figure 7: Load Data using a static resource

Have questions or want to learn more about stress testing? Contact us here.

Want more content? Check out our "Salesforce Security & Privacy Resources" page.

Subscribe to Blog