How We Implemented Skuid Testing in Provar

We recently delivered new features to help testers implement Skuid Testing in Provar. In this blog, we discuss what is involved in Skuid testing and how we implement those elements in Provar to deliver a reliable and comprehensive Skuid testing solution.

What is Skuid?

With Skuid’s no-code platform, anyone can design, develop, and deploy beautiful applications that people love using and that fit business needs —all without writing code. More than 5 million users across 32 countries use Skuid to engage with each other, with data, and with new customers in meaningful ways. Learn more at Skuid.com.

How Does Testing Work in Skuid?

Implementing Skuid testing in Provar is exciting. Changes to a Skuid page alter the XPaths. Automation test cases using XPaths need updates with these changes. This happens even with minor page changes. For example, locating two fields on a page using XPaths becomes inaccurate if another field is added at the start.

Another unique feature of Skuid testing is that Skuid has Tab Sets that contain various tabs. To properly test all these tabs, we must manually switch between accounts and write additional steps to manage this.

Finally, Skuid also has master pages that are used to create child pages. These child pages have entire master pages with some additional content. XPaths must be rewritten for each page to test all these child pages.

What Does Provar’s Skuid Testing Solution Look Like?

Provar’s unique solution to Skuid testing is integration to Skuid metadata. Provar can automatically detect when a Skuid page is changed and accommodate the change to prevent existing tests from failing. Using this intelligence, you can safely add fields or new sections to a Skuid page, knowing that existing test steps won’t break and must be fixed.

Moreover, if you add tests or amend existing ones after making changes in Skuid, the new changes will be recognized automatically.

Provar also has a solution for Skuid’s tab sets. Provar automatically switches between tabs on a Skuid page without adding extra steps, making test cases shorter and easier to understand.

Finally, when testing child pages created from master pages, Provar automatically recognizes the child page through metadata and uses the information from its master page to test the child page.

So How Does Implementing Skuid Testing in Provar Work?

Provar’s Skuid testing works as follows.

You start by setting up a connection to the Salesforce org where you want to perform your Skuid testing.

In Provar, a Connection means a set of user details that Provar can use to access your org’s metadata, which is the key to Provar’s intelligent test building.

Adding a new Connection is a quick and straightforward process in Provar:

Once this is done, you can create tests using Provar’s Test Builder. The Test Builder lets you build tests in the browser by right-clicking and selecting ‘Add to Test Case.’

The Test Builder then selects the metadata behind the target element and suggests intelligent locator access to the field in a reliable way.

Here’s an example of how it works using a standard Salesforce screen:

Provar’s Skuid testing support is versatile. You can apply the same approach to any Skuid or non-Skuid element. By right-clicking on the target element, Provar handles the technical complexities. It presents the draft test step to check before adding it to your test.

You can map Skuid pages as any standard page by right-clicking on the target element and selecting ‘Add to Test Case.’

Below is a draft test step mapping the Account ID field on this Skuid page. The only difference to a standard Salesforce page is the ‘Skuid UI Layout’ label in the top-right corner.

In addition, Provar has detected all the fields available on the Skuid page, so if you accidentally mapped the Account ID field while aiming for a different field, you can click the dropdown list and select the field.

What About More Advanced Skuid Testing?

Provar supports Skuid elements such as tables, master and child pages, lookup fields, and summary fields.

By supporting these elements so Provar automatically recognizes them, we can save you time while building your test cases, remove some of the manual effort needed to correct and update your tests, and cut down on the number of test steps your tests need to run. Below are some examples.

Example 1: Tables on Skuid pages

Provar also supports the mapping of Skuid tables.

Provar automatically recognizes tables. This allows data to be located reliably using a row number (e.g., 2) or a WHERE clause (e.g., where case origin = ’email’). This feature is useful for creating test cases that are not hard-coded to specific data. As a result, the test does not depend on the appearance of a particular record in the table.

Example 2: Skuid lookup fields

Provar also supports the mapping of particular fields, such as lookups. Note that the lookup is recognized automatically in the test step.

For example, after mapping the lookup field, the Interaction Type is automatically set to ‘SF Lookup,’ indicating that the action is to click the lookup icon. Suppose this interaction is selected, and the lookup dialog appears. In that case, Provar will automatically handle the lookup dialog, so the user does not have to add additional steps to manage the navigation. This helps reduce unnecessary test steps and the effort needed to maintain the tests.