Salesforce CPQ(Configure-Price-Quote) solution from Salesforce is based on the Lightning experience. It has some of the elements that account for a challenge – that of standard automation methods, of the likes of using Selenium.
CPQ is native for Sales Cloud or Service Cloud orgs. We need to come down to the brass stacks of “Why automate Salesforce CPQ testing?”.
Why automate Salesforce CPQ testing?
As we all know that Salesforce comes up with three automatic upgrades in a year and the same applies for CPQ too. So, it is quite a difficult proposition for the testers to test the CPQ features manually. It becomes a tedious and uphill task for the testing team.
Moreover, the CPQ is a complex product and it is indeed a time-consuming task for the testing team. So, here is where enters the automated tests. They serve the best way to achieve predictable and repeatable assessment of the quality of the custom code, in question. If you need to know “How helpful are the automated tests?”.
Then without any hesitation, we must state that the automated tests quicken the process of getting feedback. This feedback is on the quality of the custom code.
We would also like to highlight some of the challenges of Salesforce CPQ. Let us discuss some of these challenges.
Salesforce CPQ Field locators
It is difficult to handle Salesforce CPQ testing, while used with the traditional automation methods of the likes of Selenium. The Salesforce CPQ pages are said to make heavy use of shadow DOM. This is made accessible with CSS locators – not with Xpaths or even Field IDs. However, the CSS locators are unable to match with texts. So, it becomes difficult to locate shadow DOM elements.
Salesforce CPQ tabs and tables
The Salesforce CPQ pages have yet another issue. This pertains to the internal tab, controlling the fields and tables, visible under the tab. Since it requires an awareness of “active tabs”, it is difficult to control by Selenium.
The right fields are not to be found, on selecting the wrong tab. This leads to test failures.
Quote Line Editor Drawers
The Quote Line Editor Drawers can be used in quote line editors. This allows to better handle a large field set. The fields which are placed in the collapsible drawer below the line item can be accessible by clicking on the arrow, appearing at the end of the quote line. The arrow must be at the end of expanding settings, for accessing the fields below. Otherwise, it becomes difficult to handle this situation.
In this post, we will provide insights on the different types of automated tests for Salesforce CPQ and will throw some light on the guidelines for writing automated tests.
What are the Different Types of Automated Tests for Salesforce CPQ?
The various types of automated tests for Salesforce CPQ are:
- Apex Tests
- CPQ API Tests
- Selenium Webdriver UI Tests
- Lighting Component Tests
Apex tests run automatically, before and after the upgrades. There are many ways by means of which Apex tests can be used in Salesforce CPQ. Some of the examples to cite are – ordering, contracting, amending and renewal flows. In addition to this, it covers any functionality related to SObjects. However, CRUD, UI and REST services are out of the scope of Apex.
Here is a code snippet on a sample Apex test.
CPQ API Tests
The API helps to test the REST-based services on Heroku. The CPQ API tests are useful to test:
- Quote Calculator Plugins
- Quote Calculate Functionality
- Document Generation
Here is a code snippet on a sample Apex test.
Webdriver UI Tests with Selenium
Browser actions can be automated by writing tests with the Selenium framework. However, Selenium tests are only to be recommended for the complex workflows, because these are expensive to run or maintain.
These tests can be specifically recommended for client-side features an end-to-end workflow. The tests also get modified with changes in UI.
Finally, the Page Object patterns encapsulate the locators and operations – all in a single class. This is used to reduce maintenance cost and enhance readability.
Here is a code snippet on Selenium Webdriver for the CPQ QuoteLineEditor.
Lighting Component Tests
Salesforce CPQ is built on a Lightning platform and seamlessly integrates with many of the Sales Cloud features. The automation strategy evolved must have layers to map the layers in the CPQ. Here are some of the best practices on writing the automated tests.
Best Practices on Writing the Automated Tests
Test at the Right Layer
The tests must be written in the right layer. A CPQ REST API test is written if you need to write a test on a calculation. Otherwise, simply write a component test for a custom UI component.
Carry Out Mutually Exclusive Tests
The tests must set up the applications specific to the needs and has to be cleaned up, once completed. The test results produced must be the same – irrespective of the size of the test- a small or a large set of suites. However, the set up is varied, when it is complex or cost-prohibitive for automation.
Follow Single Level of Abstraction Policy(SLAP)
The test case must have the ability to do everything that is required, whatever it might be – data set up, helper methods and utility.
Limit to a Few Assertions
A test has only one thing to evaluate, so assertions must be limited to one or more only. When running tests that are expensive, it is important to remember that tests need to be split and a threshold used for the same purpose. Usually, three assertions is a good threshold. This is more so for a Black Box.
Salesforce comes up with three upgrades in a year, so the testers find it an uphill task to manually test the features of CPQ. Since CPQ is a complex product, so the testers will find it time-consuming. The automated tests quicken the process of providing feedback on the quality of the custom code, written for the purpose. There are various types of automated tests for Salesforce CPQ and testers need to adhere to some of the best practices on testing the Salesforce CPQ.