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.

Usage

It is often best to add this kind of 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

Assert parameters

In this example, the Assert is checking a specific validation error message for the Account Number field. The expected message is defined exactly 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 condition of the attribute 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 autopopulated 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

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

• Column: The Name of the Column which should be asserted. This will be autopopulated 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: Checks whether the column can be seen on the page layout.
• Heading Text: Compares the title of the column against a defined string-value.

Note: that Column Values, Column Visible and Heading Text can be set to Ignore if they are not relevant to the scenario. For example, it may be necessary only to test that the column is visible, or that the column 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 to.

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 (this will generally be prefilled by Test Builder, but the value can be changed as wanted).

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.