My final and (I feel) most important post in this series is to understand test data creation and how tests are to be executed (when, where, how long).
Creating Test Data
Test data creation can be automated in any application. Test data in Salesforce involves creating SObjects and creating records into those SObjects. This includes Accounts, Leads, Recommendations and any other data needed for testing.
Custom objects (SObjects) can be created from the Salesforce UI using the Management Settings page. For example, to create a new custom object go to Management Settings > New Custom Object.
Navigating through Salesforce pages and creating test data is a tedious process. This can be dealt with gracefully using Force.com APIs: Metadata API and REST API. Creating test data from the backend using these APIs saved lot of time while running tests. Force.com REST API was referred to me by one of my colleagues, which made me think and research if there is way to create SObjects or Fields or Field sets etc. using API. I came across the Metadata API which is used for creating SObjects.
Here are references I used for both APIs:
There are two different ways of using Metadata API: CRUD based and file based. I have used CRUD based in the scenario here. With CRUD based Metadata API, we cannot ERASE Sobjects from Salesforce (we can only delete them). In order to ERASE sObjects in the Recycle Bin, an additional script needs to be run as a maintenance task in the Org where the Selenium tests are run. Here is what I found:
[javascript title=”How to Erase sObjects in the Recycle Bin” style=”text-align:center;”]// ==/User Script==
var div=document.getElementsByClassName(“pbHeader”)[0];
if(div!=null)
{
var button=document.createElement(“input”);
button.type=”button”;
button.value=”Clean Org”;
button.addEventListener (‘click’, initClick, false );
div.appendChild (button);
}
function initClick(){
var links = document.getElementsByTagName(“a”);
var i=0;
var linkEle;
var xhttp=new XMLHttpRequest();
for (i=0;i<links.length;i++)
{
linkEle = links[i];
if(linkEle.innerHTML==”Erase” || linkEle.innerHTML==”Del”)
{
xhttp. Open(“GET”, linkEle.href,false);
xhttp. Send(“”);
linkEle.innerHTML = “Deleted”;
}
}
}
Test data can be created through the UI as well. For example, clicking on certain buttons or link texts or navigating to different Visualforce pages. If the test data creation process is through the UI and if it is the same throughout the test, my recommendation is to create test data once for a test class (this can be done using @BeforeClass annotation using TestNg framework). This saves a lot of test execution time.
Test Execution
As mentioned in the previous sections, all of the Selenium tests can be integrated with the Circle Ci build process. So every time a new build is pushed into the Org, tests start executing. These tests can be monitored for success and failure in Sauce Labs. Execution time takes hours (in my experience at least 3hrs for 300 very complex logic tests) as Selenium tests are mainly focused on traversing through UI elements. Tests can be run many times per day as needed. Otherwise merge all of the changes to the Org once a day and the Circle Ci build process will trigger the tests. This should be sufficient to track the Org status and detect bugs.
A well-defined test environment or test Org effectively helps test execution. Remember that the tests are always created making a few assumptions such as:
- Specific data exists in the Org
- Certain Iframes are present within Salesforce pages
- Permission sets for fields used by tests are in place
- Visualforce pages within Salesforce pages are already configured using page layouts.
Initially while developing tests, the stabilization of tests is a longer process. Keep the tests running in the test Org defined and monitor for failures until all of the tests are stabilized. Finally, a test report is created detailing the number of tests run and the number of tests that failed.
The Bottom Line
My overall conclusion as a person who is fairly new to Salesforce is that automating Salesforce application testing is a different experience. That said, the automation effort is very comfortable in companies where ideas are given importance and where the coordination between team members is vast.
Maintaining tests will always be an ongoing process, because of changes in test data or modifying DOM elements as required. However, this can be accomplished in less time once the automation test suite is developed and in coordination with team members.
Make sure to create an automation test plan. This helps other team members who are not part of developing tests (or the new QE person) to understand the existing testing framework of the application. Then update the test plan document throughout the project.
If you would like to read my previous posts on this subject, check them out below. Thanks for reading!
