UI Assert

Introduction

This API 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 API can also be used to check messages on a page, using a Page Assertion, or values in a column, using a Column Assertion.

Use the following links to navigate to the relevant section:

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 API 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. This is illustrated further in Example 2.

Asserting Standalone Fields vs. Asserting Fields in Tables

This API 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 API Palette.

Assert Parameters

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

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 parameter definitions 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. Any parameter can be disregarded be selecting ‘Ignore’ from the dropdown list. This will indicate that the attribute should not be checked when the Test Case is run.

Using ‘Ignore’ is recommended since, in many cases, you may only want to check the Value or the Error Message of a given field.

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 1: Asserting fields

In this example the UI Assert API 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).

Step 4: The ‘Add & Do’ button is clicked to save this Test Step, then the process is repeated to assert the Prospect field, with ‘Add & Do’ clicked 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 also that the information gathered in the Assert is visible in the Test Runner and the Variables view for each Test Step. The Result1 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, the Asserts are renamed so that their purpose can be easily understood. (Refer to Renaming Test Steps for more information.)

Example 2: Asserting picklist field values

In this example the UI Assert API is used to check that a certain option exists in the Type picklist field when creating a new Account. This is done by looping through the result to check against an expected value.

Step 1: The Test Builder is launched and the Account Edit screen is navigated to by clicking the ‘New’ button on the Accounts tab.

Step 2: The Type field is mapped as a Test Step by right-clicking on the field and selecting ‘Add to Test Case’. In the draft Test Step, an Interaction Type of ‘Read/Assert is chosen and Control Options checkbox is ticked to extract the picklist values. Then ‘Add & Do’ is clicked to add the Test Step.

Note that the Expected Attributes section will not be visible in Test Builder for some Provar versions. If this is the case, the Control Options attribute can be set to Read within Provar Desktop once the Test Step has been added:

Note that the UI Assert Test Step has been added as a sub-step under a UI On Screen Test Step. This is handled automatically by the Test Builder.

Step 3: In Provar Desktop, a loop is added to search through the Result1 variable until a specific Type option, ‘Expired’, is found. If the option is found, it is selected.

This sequence involves use of the For-EachIf and Set Values Control APIs. More information on their usage is available in the hyperlinked help pages.

Note also that the information gathered in these Test Steps is visible in the Test Runner and the Variables view for each Test Step. The Result1 variable below demonstrates the values collected from the Type field after the loop has been completed:

2017-05-12T11:34:51+00:00

Leave A Comment