- Jeff Fillegar
- Posts
- Salesforce API Test Automation with Tricentis Tosca
Salesforce API Test Automation with Tricentis Tosca
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 ReleasesSalesforce 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?
I will be using Tricentis Tosca to build automated Salesforce API test cases. Before I can get access to the Salesforce REST API, I need to create and configure a connected app in my salesforce instance.
I will be using a free Salesforce Developer instance. I’ve posted the detailed steps on how to get started here:
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.
Note: This article is not a step-by-step guide on using Tosca. This article assumes you have foundation knowledge on Tosca and have a basic understanding of APIs and Salesforce.
Free: Tosca training and certification!
Tosca Automation Specialist 1 link
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: https://login.salesforce.com/services/oauth2/token
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 FoldersTosca 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.
Summary
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.