Automation Testing in Salesforce

Automation testing is a standard tool for ensuring software quality and maintains a major role in many current dev-ops landscapes. Its speed of execution, reliability, and flexibility remain valuable despite the investment required to build up and maintain regression suites. However, for Salesforce customers, who can deliver simple functionality with just a few clicks, does the automation investment still make sense?

What Makes Salesforce Different Than Custom Development?

Salesforce, like many commercial off the shelf products, provides highly customizable business workflows hosted on its own managed architecture. Rather than worrying about writing custom code, cloud configuration, big data storage, or complex security, many companies trust Salesforce to take care of the infrastructure while allowing them to focus on meeting user needs. Because changes can be made rapidly and released through Salesforce’s pipeline, intent can be delivered quickly with a high degree of reliability.

However, since intent can be delivered so rapidly, finding the right balance of testing for Salesforce can be tricky. Too little, and that casual tweak to permissions just locked out half of your user base from completing their day’s work. Too much, and you are spending 10 hours testing what took only 10 minutes to configure, and that much-anticipated production feature is held back for little reason. When striving for this ideal, there are three important considerations which allow you to tune your testing framework to best balance speed of delivery with quality assurance.

Take a Multi-Tool Approach

When the topic of automation testing is broached, the first thought often goes to some sort of selenium-based UI testing. Meant to simulate a user interacting with a browser, this style of testing does a fantastic job of covering end-to-end workflows, ensuring users can complete their primary functions. In addition, UI testing also pairs well with behavior driven development, a method of expressing requirements in natural language for the purpose of collaboration between product, development, and testers.

When it comes to Salesforce, however, many of the UI components are being generated out of the box, without custom code. Testing each layout change, new field, or data validation with UI scripts can quickly snowball into a massive regression suite as your application matures. A bloated regression script is one of the biggest threats to the speed of development pipeline, and as it grows the inevitability of false-positives and time-consuming maintenance wears down your testers.

Instead, consider at least three different toolsets when considering how to test a new Salesforce configuration.

Apex

Salesforce provides the ability to configure its product via a custom language called Apex. When creating features through Apex, its is strongly recommended that the Apex code is properly unit tested with Apex test classes. In addition, the Apex test classes provide a very valuable framework for testing larger features, even those created through click-configuration.

For example, let’s say you added some logic so that your Opportunity object would display a custom field value after creation, based on another field input by the user. This would be very simple to test via Apex test classes, and you could easily expand the test to cover several user inputs if there was any custom logic needed. Because Apex test classes do their own data cleanup, have a dedicated execution framework, and can be run on deployment, it takes very little investment to integrate them into your pipeline.

When considering whether a feature is best covered by Apex test classes, asking the following questions can be helpful:

• Do I understand the configuration enough to isolate and cover it with a focused test?
• Does this require a complicated data setup that would be difficult to do on the UI?
• Is there a broadly-branching logic tree?
• Are there many different data permutations?
• Is this a one-time event in the workflow, like a validation rule?

If you answer “yes” to one or more of these questions, Apex test classes could provide a quick, Salesforce-supported framework for testing that feature.

API

Salesforce supports several types of service endpoints for accessing their product. These endpoints support modern API architectures like REST and can be used to access custom Apex functions or to interact with Salesforce provided objects like Case or Account. Though it’s not necessary to test the out of the box APIs provided by Salesforce, some companies chose to write their own APIs with custom business logic.

If this is the case, is it wise to test the new endpoints directly via tools like Postman or SoapUI. This allows you to ensure the API is functioning as intended, regardless of who is consuming it.

Selenium Scripts

As we touched on above, common UI testing architecture is often browser based, and articulates tests in natural language. These scripts excel in testing business workflows as a user would experience them, providing end-to-end testing through the full tech stack. Utilizing languages such as Javascript or Ruby, the crafting and executing of these scripts can be as time intensive as actual feature development. Because of the skill and time needed to write useful, reliable, and efficient UI tests, it is best to think carefully about each test you add to the UI suite, and make sure it is a good investment.

Here are a couple questions to ask before writing a selenium script:

• Does this test cover a business workflow that is critical to user success?
• Will this test run reliably, without false positives or excessive execution time?
• Is there any UI-specific behavior than needs to be covered?
• Can this test be articulated in natural language, and be easily understood in our test reports?

If you answer “yes” to most of these questions, the feature is a good candidate for a well-crafted UI script. If not, consider if one of your other testing tools is a better fit.

Selecting the right tools is a major component to creating a comprehensive, balanced Salesforce automation suite. With proper mix of technologies, you can then tackle the difficult technical aspects of testing the Salesforce platform. Please see part two of these series for tips on making your suites portable, efficient, and modular.