Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • Now Platform App Engine
Table of Contents
Choose your release version
    Home Orlando Now Platform App Engine Now Platform App Engine Application tools Automated Test Framework (ATF) Building and running automated tests with the Automated Test Framework UI test steps Custom UI test steps

    Custom UI test steps

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Custom UI test steps

    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.
    • Date
    • Date Time
    • Reference

    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
    Page displaying KB0011110 "ServiceNow Secure Coding guide for Instance developers"
    For example, these page components require custom UI test steps.
    1. The number of article views.
    2. The buttons to mark the article as Helpful.
    3. 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.
    1. Navigate to Module. Navigate to the 'Published' module in the 'Knowledge' application.
    2. Open an Existing Record. Open the 'Knowledge' form with id 'Knowledge: KB0011110'.
    3. Click a UI Action. Click UI Action 'View Article' on 'Knowledge' form.
    4. Assert Text on Page (Custom UI). Assert that the text 'developers' is on the page.
    5. 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.
    6. Click Component (Custom UI). Click the component: 'Button <button>: Comment'.
    7. 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
    Screenshot displaying example test with seven test steps.
    • Page Inspector

      Identify the HTML and JavaScript page components in your user interfaces that are available for custom UI testing. Enable automated testing by ensuring that your user interfaces only contain testable page components.

    • Enable and use the page inspector

      Enable a developer setting to inspect UI pages that open within the platform. Use the Manual Page Inspector to inspect pages that open in a new tab, such as Service Portal pages.

    • Create a custom UI test

      Test components in custom UI pages.

    • Override component test actions and data type

      Change the testing properties of a particular page component using Automated Test Framework-specific HTML attributes.

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Custom UI test steps

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Custom UI test steps

      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.
      • Date
      • Date Time
      • Reference

      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
      Page displaying KB0011110 "ServiceNow Secure Coding guide for Instance developers"
      For example, these page components require custom UI test steps.
      1. The number of article views.
      2. The buttons to mark the article as Helpful.
      3. 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.
      1. Navigate to Module. Navigate to the 'Published' module in the 'Knowledge' application.
      2. Open an Existing Record. Open the 'Knowledge' form with id 'Knowledge: KB0011110'.
      3. Click a UI Action. Click UI Action 'View Article' on 'Knowledge' form.
      4. Assert Text on Page (Custom UI). Assert that the text 'developers' is on the page.
      5. 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.
      6. Click Component (Custom UI). Click the component: 'Button <button>: Comment'.
      7. 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
      Screenshot displaying example test with seven test steps.
      • Page Inspector

        Identify the HTML and JavaScript page components in your user interfaces that are available for custom UI testing. Enable automated testing by ensuring that your user interfaces only contain testable page components.

      • Enable and use the page inspector

        Enable a developer setting to inspect UI pages that open within the platform. Use the Manual Page Inspector to inspect pages that open in a new tab, such as Service Portal pages.

      • Create a custom UI test

        Test components in custom UI pages.

      • Override component test actions and data type

        Change the testing properties of a particular page component using Automated Test Framework-specific HTML attributes.

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login