With three automatic upgrades released each year, finding time to test the latest Salesforce CPQ features manually can be tedious and time-consuming due to the product’s complexities. Automated tests are the best way to achieve predictable and repeatable assessments of the quality of your custom code and configuration. With these testing tips, you can begin your automation strategy for Salesforce CPQ customizations at the right layer.
You may be asking “What does CPQ mean?” CPQ stands for Configure, Price, Quote and is a native add-on for Sales Cloud or Service Cloud orgs. If you’re new to CPQ, you can learn more here.
Automated testing allows you to quickly get feedback about the quality and health of your custom code and configuration. In this article, we explore four kinds of automated tests that are useful when testing your CPQ flows.
Let’s start with some general guidelines for writing automated tests:
- Test at the right layer. Full Integration UI tests are easy to conceptualize, but hard to run and maintain. Write tests at the right layer. If you want to test only calculation, consider writing a test using the CPQ Calculate Quote API. If you’re writing a custom UI component, write component tests.
- Keep it to very few assertions per test. A test should almost always evaluate only one thing, so ideally you can have only one or at most a few assertions. However, when writing tests that are expensive to setup or run, it’s best to use a threshold to break tests down. We recommend three assertions as a good threshold to use. This is particularly important when dealing with a Black Box as it’s easy to get carried away and write very complex scenarios.
- Keep tests mutually exclusive and idempotent. Every test should set up the application to its needs and clean up when done. A test should also produce the same result no matter how you run it — individually, as a small suite, as a large set of suites etc. You can have some variations if setup is very complex or cost-prohibitive to automate, but it’s generally a good principle to focus on.
- Follow the Single Level of Abstraction Principle (SLAP). A test case should do everything that it needs using data setup, utility and helper methods, but should make calls to them inline.
The Salesforce CPQ application is built on the Lightning Platform using many Sales Cloud features while seamlessly integrating with them. The CPQ application is made up of a UI backed by a powerful set of APIs that can be accessed using the SOAP or REST protocols. This way, you can break down your automation strategy into layers that map to the layers of the CPQ application.
Here are four kinds of automation tests that you can develop to throughly test Salesforce CPQ,
1) Apex tests
Apex tests run automatically before and after upgrades in the Apex test harness. In Salesforce CPQ, Apex tests can be used to validate contracting, ordering, amend and renewal flows along with any functionality based on SObject CRUD. UI and REST services are not covered during Apex.
Here’s a sample Apex test you can write to validate that Contracts get amended correctly. To do this we’ll create a ‘ContractAmender’ class like defined below. This class amends a contract using the Salesforce CPQ Contract API, but you could replace this with any custom logic. Also, before adding these classes, make sure you create the CPQ Model classes as described here.
Have you earned your Apex Testing badge on Trailhead? Get it here!
2) CPQ API tests
Use your favorite test harnesses to write tests using the CPQ API. The API allows you to test the REST-based services. Use the CPQ API to test your quote calculate functionality, quote calculator plugins, document generation, and more. For example, you can write a test that reads a quote with product(s), calculates the quote and saves it.
Here’s a simple example in Apex that uses QuoteAPI.QuoteReader to test if quotes can be read.
Learn more about the CPQ API here!
Tip: You can also write tests in Java using Junit or TestNG as a test harness and a framework like Rest-Assured. If your team is more comfortable with JS, Frisby is a useful REST API testing framework.
3) Selenium Webdriver UI tests
Use your favorite test harness to write tests using the Selenium framework to automate browser actions. Because Selenium tests are expensive to run and maintain, they should be used only for critical flows. We recommend using Selenium tests for client-side features like option constraints and end-to-end flows. Note that Selenium tests are subject to modification when the UI changes. The Page Object pattern encapsulates all the locators and operations one can do with them in to a single class. Use it to reduce the cost of test maintenance and to improve readability. Check out this reference on Selenium HQ to learn more about PageObjects.
Here’s a sample Page Object written in Java using Selenium Webdriver for the CPQ QuoteLineEditor:
Use the “CpqQuoteLineEditorPage” PageObject as shown below:
Tip: Write your tests in Java with Junit or TestNG as a harness and use Selenium / Webdriver to interact with the browser. If you’re more familiar with JavaScript, Mocha with Selenium / Webdriver is also a great option. Selenium provides clients in a number of languages like Perl, Python, Ruby, C# etc.
4) Lightning Component tests
If you’re writing custom Lightning components, the Lightning Testing Service (or LTS) is a set of tools and services that let you create test suites for your Lightning components using standard JavaScript test frameworks, such as Jasmine and Mocha. LTS has many great features built in, so you can jump right in to writing tests for your components. The GitHub repository above has a lot of great code samples. If you don’t write any custom lightning component, you won’t have any tests in this category. If you’re already using other component-based frameworks like Polymer or React, consider writing tests using their testing frameworks.
Ready to get started?
We recommend running your automation against Salesforce DX scratch orgs. The Package Development Model Trailhead module is a great place to get started with scratch orgs.
I hope this post helped you learn more about about the ways you can automate your testing of Salesforce CPQ. If you have any questions or thoughts, feel free to leave a comment below or Tweet me at @NAthmaraman.