Looking for something in particular?

UI Assert

This test step checks the values or attributes of a UI field and compares them to the expected values. This is most useful for when fields on a UI need to have their values and/or behavior checked in a functional testing flow. This test step can also be used to check messages on a page, using a Page Assertion, or values in a column, using a Column Assertion.


It is often best to add this test step through the Test Builder by mapping the field and selecting an Interaction Type of Read/Assert. This is recommended as the fastest way to add this kind of test step, although it is also possible to use drag-and-drop from the Test Palette.

A UI Assert can test the following:

  • Field values
  • Field attributes (e.g., Read Only, Visible)
  • Messages thrown on operations like Save (e.g., validation rule error messages, page-wide messages)
  • Column header names in tables (e.g., a related list)
  • Column values
  • Count or number of items in a column

Adding multiple asserts

Note that more than one Assert can be added to a single test step, providing that the Asserts are all of the same type (see Asserting Fields vs. Asserting Fields in Tables below). The best method for doing this is to use the icons identified below.

If multiple Asserts are used in the same test step, the result of the assertions will be stored in a list.

Asserting standalone fields vs. asserting fields in tables

This test step can be used against specific fields on a page or for fields under a table structure, such as a related list. When testing against a specific field, the Assert test step should be added as a sub-step under a UI On Screen test step. When testing against a field in a table, the Assert test step it should be added under a UI With Row test step. These test steps are added automatically when using the Test Builder. This approach is generally recommended over using drag-and-drop from the Test Palette.

Assert parameters

The screenshot below shows an Assert’s parameters in use.

In this example, the Assert checks a specific validation error message for the Account Number field. The expected message is defined precisely, and it is Case Sensitive.

In addition, this Assert will also Read whether the field is Visible and will check that the field equals Read Only. Note the difference between Read (to capture an attribute and place it in a Results variable) and Equals (to test for a specific attribute condition and return TRUE or FALSE).

The full Field Assertion attributes are as follows:

  • Field: The name of the field to be asserted. This will be auto populated based on the UI On Screen or UI With Row parent Test Step
  • Value: Defines any expected field value
  • Message: Defines any expected validation message against the field (e.g., after Save is clicked)
  • Visible: Checks whether the field is visible on the page layout (based on the permissions associated with the user credentials through which the Salesforce Connection has been made)
  • Disabled: Checks whether the field is disabled or enabled
  • Read Only: Checks whether the field is Read-Only or Editable
  • Focused: Checks whether the tab focus is on the current field
  • Inline Editable: Checks whether the field can be ‘inline edited’, i.e., editable from the View screen without navigating to the full Edit screen
  • In View: Checks whether the field is visible onscreen without scrolling based on the current browser size
  • Options: Checks the metadata options available for the field (applies to picklist fields only)

Note that these parameters are optional except for Field. The other parameters will appear when selected from Test Builder or when clicking the Add the Field Assertion Attributes located in the Test step parameters.

The full list of operators is as follows:

  • Ignore: Shows that an attribute should not be checked
  • Read: Captures the attribute and places it in a Results variable
  • Equals: Checks an attribute against an expected string (returns TRUE or FALSE)
  • Contains: Checks whether the attribute includes a defined value-string within it (returns TRUE or FALSE)
  • Starts with: Checks whether the attribute begins with a defined value-string (returns TRUE or FALSE)
  • Ends with: Checks whether the attribute ends with a defined value-string (returns TRUE or FALSE)
  • Matches: Matches the attribute value with a defined value-string (returns TRUE or FALSE)

Page assertions

To test messages on a page, a Page Assertion can be used. This will capture all messages in a list, which can then be checked against a defined string value.

Column assertions

A Column Assertion can be used to test the attributes or values of a column within a table. This has the following parameters:

  • Column: The Name of the Column which should be asserted. This will auto-populate based on the table captured in the UI On Screen or UI With Row parent test step.
  • Column Values: Reads the number and values of all the column items and adds them to a list.
  • Column Visible: Check whether the column can be seen on the page layout.
  • Heading Text: Compares the column’s title against a defined string value.

Note that Column Values, Column Visible, and Heading Text can be set to Ignore if they are irrelevant to the scenario. For example, it may be necessary only to test whether the column is visible or has a specific title.

Example: Asserting fields

In this example, the UI Assert test step is used to assert the value and some attributes of the Account Name field and the Type picklist field.

Step 1: The Test Builder is launched, and a specific Account record is navigated.

Step 2: The Account Name is mapped as a test step by right-clicking on the field and selecting Add to Test Case.

Step 3: The Draft test step is configured as follows:

Note that the Expected Attributes section will not be visible in Test Builder for some Provar versions. These attributes can be configured within Provar Desktop once the test step has been added.

The Extract Value and Assert Value checkboxes are both ticked. The Expected Value is set to the name of the Account (Test Builder will generally prefill this, but the value can be changed as wanted).

Step 4: The Add & Do button is clicked to save this test step, then the process is repeated to assert the Prospect field, with the Add & Do click after the draft test step has been configured.
Step 5: Reviewing the new test steps in Provar Desktop, note that the UI Asserts have been added as sub-steps under a UI On Screen test step (used to navigate to the Account view screen). This hierarchy has been created automatically by the Test Builder.

Note: The information gathered in the Assert is visible in the Test Runner and the Variables view for each test step. The Values variable demonstrates the values collected through the Account Name Assert.

The execution results are also visible in the Test Builder by right-clicking on a given step and selecting View Test Step Output.

Step 6: To complete the test steps, you can rename the UI Assert step so that their purpose can be easily understood.

Review Provar on G2
Documentation library

Trying to raise a case with our support team?

We use cookies to better understand how our website is used so we can tailor content for you. For more information about the different cookies we use please take a look at our Privacy Policy.

Scroll to Top