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 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
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)
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.
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.
Step 6: To complete the test steps, you can rename the UI Assert step so that their purpose can be easily understood.
- General information
- Licensing Provar
- Provar trial guide and extensions
- Using Provar
- API testing
- Behavior-driven development
- Creating and importing projects
- Creating test cases
- Custom table mapping
- Debugging tests
- Defining a namespace prefix on a connection
- Defining proxy settings
- Environment management
- Exporting test cases into a PDF
- Exporting test projects
- Managing test steps
- Namespace org testing
- Provar desktop
- Provar Test Builder
- Refresh and Recompile
- Reload Org Cache
- Running tests
- Searching Provar with find usages
- Secrets management and encryption
- Setup and teardown test cases
- Tags and Service Level Agreements (SLAs)
- Test cycles
- Test plans
- Testing browser options
- Tooltip testing
- Using the Test Palette
- Test Palette introduction
- Control test steps
- List compare
- Read test step
- String test steps
- UI Test Steps
- Using custom APIs
- Callable tests
- Data-driven testing
- Page objects
- Block locator strategies
- Introduction to XPaths
- Creating an XPath
- Label locator strategies
- Maintaining page objects
- Mapping non-Salesforce fields
- Page object operations
- Refresh and reselect field locators in Test Builder
- Using Java method annotations for custom objects
- Applications testing
- Database testing
- Document testing
- Email testing
- Mobile testing
- OrchestraCMS Testing
- Salesforce CPQ testing
- ServiceMax testing
- Skuid testing
- Vlocity testing
- Webservices testing
- Introduction to test scheduling
- Apache Ant
- Configuration for sending emails via the Provar Command Line Interface (CLI)
- Continuous integration
- Azure DevOps
- Running a Provar CI task in Azure DevOps
- Configuring the Provar secrets password in Microsoft Azure Pipelines
- Parallel execution in Microsoft Azure Pipelines using multiple build.xml files
- Parallel execution in Microsoft Azure Pipelines using targets
- Parallel execution in Microsoft Azure Pipelines using Test Plans
- Bitbucket Pipelines
- Circle CI
- GitHub Actions
- Running a Provar CI task in GitHub Actions
- Remote Trigger in GitHub Actions
- Parameterization using Environment Variables in GitHub Actions
- Parallel Execution in GitHub Actions using multiple build.xml files
- Parallel Execution in GitHub Actions using Targets
- Parallel Execution in GitHub Actions using Test Plan
- Parallel Execution in GitHub Actions using Job Matrix
- GitLab CI
- Travis CI
- Parallel Execution
- Running Provar on Linux
- Salesforce DX
- Team foundation server
- Version control
- Zephyr Cloud and Server
- Salesforce testing
- Adding a Salesforce connection
- Assert Page Error Messages on Add/Edit Product
- Dynamic Forms
- Internationalization support
- List and table testing
- Salesforce Release Updates
- Salesforce Lightning Testing
- Salesforce Lightning Web Component (LWC) locator support
- Salesforce console testing
- Visualforce Testing
- Testing best practices
- Configurations and permissions
- Error messages
- Licensing, installation and firewalls
- Test Builder and test cases
- Release notes