Salesforce API Test Automation

In this article, I will show how to build Salesforce API automated test cases using Tosca.  Tosca is a no-code visual test designer, which lowers the technical barrier for anyone to build robust automated test cases irrespective of the technology under test.  Before we get into how we will build the test cases, let’s first understand the scope of the Salesforce API in respect to test planning and test design. 

What value does the Salesforce API bring to quality engineering teams?  Teams obviously need to functionality test the Salesforce API to ensure it is working as expected.   The API can also be leveraged in other aspects of quality engineering, primarily around test data and integration testing scenarios. 

Before we look at how to build automated API test cases, I think it is important to understand the 4 categories of Salesforce releases so that we can test plan more efficiently which ultimately will reduce our test design and maintenance time.

Salesforce’s cloud-based architecture

While Salesforce’s cloud-based architecture and easy extensibility make it a powerful tool for innovation, there is also a catch. Because Salesforce focuses on an organization’s most critical data and business processes, any update, extension, customization, and integration must be thoroughly tested. 

Top 4 categories of Salesforce releases

The top 4 categories of Salesforce releases that quality engineering managers, devops engineers, and testers need to plan for are:

  • Salesforce Platform Releases

    Salesforce has three major releases per year and many additional patches throughout the year:

    • Winter Release – usually planned for November
    • Spring Release – typically planned for March
    • Summer Release – typically planned for July
  • Releases from Salesforce AppExchange vendors
    • Over 86% of Salesforce customers (and 100% of Fortune 100 companies) have at least one app from the AppExchange. These apps are updated according to the timeline of their third-party vendor
  • In-house customizations
    • These include customizations deployed through your development process as well as ad-hoc changes implemented by business users with the right permissions
    • Changes or updates to web to lead
    • Changes or updates to CPQ
    • Data updates, migration, cleansing, reporting, etc
  • Integration Releases from other applications either custom apps or other vendor ERPs like:
    • SAP, Oracle, JD Edwards, Service Now, etc
    • ETL data pipelines and reporting tools 
      • Snowflake, Tableau, Power BI, etc

Wow! – That’s quite a lot of work to manage and ensure that the critical business processes that depend on salesforce and other applications to run the day-to-day operations work as expected.  

However, there is one commonality that all 4 salesforce release categories have that can save quality engineering teams time and that is the Salesforce REST API

The Salesforce REST API

Quality Engineering and test teams are already testing the Salesforce API so why not leverage the automated test cases for other aspects of testing.  Building reusable API automated test cases allow quality engineering to:

  • Reuse automated API test cases to data-drive Salesforce GUI automated test cases
  • Data-drive the test cases across functional, integration, and end-to-end testing scenarios
  • Manage Test Data – find, create, update, and delete data used in development, functional testing, and integration testing scenarios

Let’s look at some examples of how we can design Salesforce API automated test cases with no-code using Tricentis Tosca.

How do we build no-code test automation for the Salesforce API?

Creating No-Code automated API test cases using Tosca

Now that our Salesforce instance and Tosca workspace are ready, we can create our first Salesforce API automated test case.  Every Salesforce API test case will need an authentication token or the test case will fail. 

What will we build?

Screen shot of my SFDC API Get Auth Token Tosca Test Case:



I have the SFDC API Get Auth Token in a Reusable TestStepBlock in my Library folder.  This enables me or anyone using Tosca to add that automated test step to their own test case.    

How to automate the SFDC API Get Auth Token Test Case using Tosca

The first step for any API automated test case using Tosca starts in the Tosca API Scan tool.

  • Create a Message and rename it “GetToken”.  Then configure the API Test Case with the following:
  • Method: POST
  • Endpoint:
  • Populate the Params Tab with your Salesforce credentials.
    • grant_type: password
    • client_id
    • client_secret
    • username
    • password

Configure the Auth Tab.  The Redirect URI was created with your SFDC Connected App. 


Click Run. The Response will look like the following:


If you get anything other than a 200 OK then the credentials supplied in the request are not correct.  We got an access_token back so our credentials and Connected App were setup correctly. 

Export API Test Case to Tosca Commander

Click the API Test Case button and the API request and response will be converted to an automated Tosca API Test Case. 

  • Modules in Tosca are the foundation for the Model Based Testing Approach

Tosca Grey Component Folders
Tosca creates the modules and test cases in a grey component folder.  Tosca API Test Cases will contain 2 modules, 1 for the API Request and 1 for the API Response.  Tosca automatically creates the corresponding automated API test case as well.


Tosca Module Folder Structure

I typically move the modules and test cases to the folders where they will reside and then began working with them. 

Example of how I have structured Tosca to manage the modules for Salesforce, SAP,  web, .NET, Java, APIs and databases.  I have also added the parameters as module attributes to the GetToken request and response modules.



Since I know that the GetToken API test case will be reused by every single SFDC API Test Case then I will drag and drop the GetToken API test case into the Library folder.  Tosca automatically creates a Reusable TestStepBlock for us. 

Add the Configuration Parameters to the GetToken Request and buffer the access_token in the GetToken Response.


Reducing Test Case Maintenance time

Now anyone using Tosca can add the SFDC API Get Auth Token Reusable TestStepBlock to any of their SFDC API Test Cases.  If Salesforce changes the requirements for their token service, then we only have to update the GetToken Modules and then every test using them will automatically get updated – lowering our maintenance time tremendously.

Ready to Execute

Click Run in Scratchbook from the Test Case Ribbon or right-click and select Run in Scratchbook.  The SFDC Auth Token in returned in the response of the test case and is saved into the buffer variable called Token.  Now we can pass the Token into the header for any Salesforce API automated test case.


In this article, we learned how to automate the Salesforce API Get Token Service test case in Tosca.  Tosca’s No-code visual test designer makes it easy to create, execute, and maintain automated test cases.  No-code!  Stop writing code to test code.  If you want to write code, then build products not test cases.

In the next article, we will learn how to automate Salesforce APIs for CRUD operations for Leads.  For each SFDC API Request, we will add the SFDC API Get Auth Token Reusable TestStepBlock as the first step in our test case and pass the Token to the Request of the next API test case step.