Test customized user interfaces such
as UI pages and UI macros by retrieving their HTML and JavaScript page
components and identifying the test actions they support.
Custom UI test steps require the Automated Test Framework to retrieve and identify the
testable components from a target web page.
Testable components
Testable page components consist of standard HTML and JavaScript with these
characteristics.
Are set or clicked by user interaction
Testable page components allow users to set a value or click them.
Are accessible from the Document Object Model (DOM)
Testable page components are accessible from the DOM and support JavaScript manipulation of
the DOM. Custom UI test steps cannot access page components in the shadow DOM.
Are accessible to JavaScript
Testable page components are accessible to JavaScript. Custom UI test steps cannot access
page components that interact directly with the operating system such as file fields or
display non-HTML content such as Excel or PDF files.
New browser tabs or windows are not supported by Custom UI test steps.
Are not excluded from custom UI testing
Testable page components are not excluded from custom UI testing. Automated Test Framework excludes page components
that are already testable by other test step categories and also excludes page components
associated with Now Platform
features.
Are accessible to the Page Inspector
Testable page components must return results when viewed from the Page Inspector . Test designers can use the Page Inspector to identify the
testable components of a page.
Examples of testable page components include these UI elements.
Buttons
Links
Page text
UI controls
UI macros
ui_date
ui_date_time
ui_reference
UI pages
Wizards
Examples of untestable page components include these UI elements.
Table 1. Example untestable page components
Reason untestable
Untestable page components
Are not settable or clickable
Hidden controls
HTML comments
HTML layout elements such as div, section, and span.
HTML script elements
Are inaccessible from DOM
Dashboards
Images
Lists
Reports
Shadow DOM
Are inaccessible to JavaScript
Excel files
File fields
PDF files
Are Now Platform
features
Flow Designer
Studio
Upgrade Monitor
Are testable by other test step categories
Form field labels
Form field values
Service Catalog
Workspaces
Settable page components
A settable component is a UI element that has a dynamic value such as a text
input field. Settable components support these test actions and test steps.
Table 2. Test options for settable components
Page Inspector actions
Custom UI test steps
Set Component Value
Set Component Values (Custom UI)
Get Component Value
Assert Text on Page (Custom UI)
Component Value Validation (Custom UI)
Is Component Disabled
Component State Validation (Custom UI)
Settable components have a data type that
determines what values a Custom UI test step can set. For example, a page component
intended to display a reference to a particular record can have a reference data type to
only display Sys ID values.
Automated Test Framework allows UI developers to
specify a data type to use during custom UI testing. UI developers can assign page
components a data type to ensure that a test step sets a valid value. These data types are
supported.
See Override component data type for more information.
Clickable page components
A clickable component is a UI element that users can interact with by clicking
such as inputs of type check box or radio. Clickable components support these test actions.
Table 3. Test options for clickable components
Page Inspector actions
Custom UI test steps
Click On Component
Click Component (Custom UI)
Get Component Value
Assert Text on Page (Custom UI)
Component Value Validation (Custom UI)
Is Component Disabled
Component State Validation (Custom UI)
Clickable components do not have a data type since they do not have dynamic values.
Retrieved page components
Automated Test Framework stores a list of the
retrieved page components for each custom UI page you test. Custom UI test steps display the
list of retrieved components from the Component and Component
values fields.
By default, the list of page components is static and is only updated when Test designers
manually click Retrieve Components . Administrators can enable the system
property sn_atf.page_data_capture.enabled to refresh the list of page
components every time a Custom UI test step is run. Enabling this property during test design
ensures that your test designers always have access to the most current list of page components.
Disabling this property after test design is complete allows your tests to run faster because
test steps can use the previously retrieved list of page components.
The Now Platform treats the list of
retrieved page components as data and does not include them in update sets or applications
files. When transferring tests from one instance to another, test designers must manually
retrieve page components again.
Design considerations
Follow these design considerations when testing custom UI pages and page components.
Use the page inspector to identify testable page components
The page inspector determines which page components are available for custom UI testing.
Page components that are unavailable to the page inspector are unavailable to custom UI
testing.
Navigate to the custom UI you want to test
Use existing test steps to navigate to the target custom UI. For example, to test a
Knowledge Base article, use the existing test steps to navigate to a module or to open an
existing record. Most custom UI testing requires using existing test step categories as part
of the test.
Use the component area to identify page components
The component area describes the HTML layout element containing the component such as a
<div> or <section> element. The area helps test
designers distinguish between components by providing the location in the page layout.
Test your custom UI rather than Now Platform UI
The Automated Test Framework prevents custom
UI testing of Now Platform features. For
example, you cannot test dashboards or graphical designers. Instead, build tests to validate
your custom UI pages and elements since you have direct control over these user
interfaces.
Use HTML attributes to override page component testing properties
Change the testing properties of a
particular page component using Automated Test Framework -specific HTML
attributes. See
Override component test actions and data type .Retrieve page components again when you move tests to another instance
Custom UI test steps do not store UI components as metadata. Testers must manually retrieve
page components again when moving tests between instances.
Example custom UI testing
You can use the list of retrieved components to design custom UI test steps. For example,
suppose that you want to test reviewing and commenting on a Knowledge Base article. A Knowledge
Base article contains several page components that require custom UI steps to test.
Figure 1. Example Knowledge article page
For example, these page components require custom UI test steps.
The number of article views.
The buttons to mark the article as Helpful .
The text area to Leave a comment .
These steps demonstrate custom UI testing on a Knowledge Base article. The example test
consists of these existing and custom UI test steps.
Navigate to Module . Navigate to the 'Published' module in the
'Knowledge' application.Open an Existing Record . Open the 'Knowledge' form with id
'Knowledge: KB0011110'.Click a UI Action . Click UI Action 'View Article' on 'Knowledge'
form.Assert Text on Page (Custom UI) . Assert that the text 'developers'
is on the page.Set Component Values (Custom UI) . Set the components on the page as
follows: 'Textarea <textarea> [article_comments]' = Update with actual article rather than
URL to article elsewhere.Click Component (Custom UI) . Click the component: 'Button
<button>: Comment'.Assert Text on Page (Custom UI) . Assert that the text 'Update with
actual article rather than URL to article elsewhere.' is on the page.
Figure 2. Example test steps for a knowledge base article test
