Testing a Salesforce app with Provar

Here at Nintex, we are leaders in Intelligent Process Automation by creating more time, more productivity, and less busy work with our advanced workflows. For years we have been building apps on the Salesforce platform. We have always relied heavily on Apex test methods to validate the back-end functionality of our applications, but what about the front-end?

User Interface Testing, or UI Testing, is the testing of visual details like images, colors, and styles, but also functional behavior including controls, navigation, error messages, data entry handling, application flow, and much more.

Starting from scratch, producing Automated UI Tests seemed challenging because we would be introducing a new process. We knew we had to do something after looking at the benefits:

  • Save time and resources from manual testing, including duplication of tests between multiple browsers and devices
  • Prevent regression errors
  • Reduce margin of human error
  • Increase efficiency
  • Consistency

Then we discovered Provar.


Provar

Provar is a point-and-click, no code, GUI-based software. Although the application is easy to install and start using, it comes with a robust set of powerful features built in. It’s easy to connect to Salesforce, Microsoft, and Google so you can get straight to writing tests.

A Provar test case consists of an ordered list of test steps. Steps are created by dragging one of the many Test API actions onto the test case.

Test Actions

The Provar User Interface APIs allow a test action to interact with the UI. For instance, a set of actions can enter text into a form, check a checkbox, and then click a button. We can then use another action, the UI Assert API, to verify that we see a success message.

Control APIs serve a different purpose. These control the logistics of the test case itself. There are actions to wait for a page to load or run test actions in a loop. Our most commonly used action is the Finally API because it runs whether the test passes or fails and we can tear-down processes.

For anyone testing Salesforce applications like us, another very useful action is the Apex Execute API. Instead of making steps to click and navigate around to update record data, we can make a single Apex Execute step to update the record all at once, which is significantly faster.

At one point we realized that many of our tests were repeating the same steps: navigate to a record, click a button, and then be brought to another page. At first we made use of “callable” tests. These are groups of test steps that can be reused inside other tests and are especially useful for things like setup and tear-down.

We wanted to take it a step further. After landing on the second page, we wanted to test the UI differences when updating URL parameters. We replaced our “callable” step with a Custom API. While Provar does not require the use of code, it does allow for creating APIs with custom code. We made our own Navigation API to handle all of the navigation and URL updates in a single test step.

Behavior Driven Development APIs allow us to organize our tests with a Given-When-Then format. Although they do nothing functionally, they help to organize test steps and make the overall test more readable.

Sample Test

Our Salesforce app, Nintex DocGen for Salesforce, provides users the ability to generate documents dynamically based on record details. The image above shows an actual Provar test.

GIVEN: A DocGen Package that will generate a file named after a Salesforce record

WHEN: We run the DocGen Package

THEN: Assert our download link appears with appropriate record name and file extension

Test Builder

The Test Builder allows you to build your test while the UI is open. This makes it much easier to add steps to a test because you can actually look at and interact with the browser. It is especially helpful when debugging a failing test because the Test Builder will pause at the failing step, giving a chance to make updates on the fly, save, and then continue running the fixed test.

Variables

Variables can be used to store information acquired during a test step and used in a later step. Clicking on a step in the Test Runner will display a variable’s value at that point in the test. In the screenshot, you can see that a new variable, adminTabId, was created during the step, Get DocGen Admin Tab Id, and it’s value is displayed on the right.

Browser Testing

As consumers can use any browser they please, the ability to test the same actions on multiple browsers is invaluable. Testing with different browsers in Provar is as simple as selecting a browser option from a select list in the menu.

Scratch Orgs

Provar’s integration with SFDX allows us to configure our tests to run on scratch orgs. This means that as soon as a developer makes a change we can quickly run our Provar tests against it. For example, we can automatically run our Smoke Test suite as soon as a pull request is made to ensure that key functionality of our app is still working as desired.

Conclusion

Currently, our tests are version controlled and automatically run nightly. We are continually adding more tests as part of our development life cycle.

We have been using Provar’s automation software for a little over a year. In this time, we have been able to go from 0% to 95% UI test coverage. Provar has a quarterly webinar which always provides us insight on their latest features and how they are keeping up with supporting the newest Salesforce technologies. To learn more check out: https://provartesting.com.
 
If you have any questions or feedback about Provar or UI Testing, please feel free to reach out or leave a comment.