Automated Test Framework design considerations

  • Release version: Zurich
  • Updated July 31, 2025
  • 5 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Automated Test Framework design considerations

    These design considerations guide ServiceNow customers in creating reliable, scalable, and efficient automated tests using the Automated Test Framework (ATF). The guidance focuses on preventing test conflicts, managing test data properly, and optimizing test execution, especially in parallel and custom UI testing scenarios.

    Show full answer Show less

    General Testing

    • Avoid modifying ServiceNow system tables or any tables extending Application File [sysmetadata] to prevent unpredictable system behavior.
    • Do not use or modify existing records in tests; instead, create new records during the test to ensure consistent test state and avoid conflicts.
    • Avoid actions such as impersonating existing accounts, deleting records, or disabling business rules, as these can cause unexpected results.

    Parallel Testing

    • Design tests to run in parallel to reduce overall test execution time.
    • Prevent resource conflicts by ensuring tests create their own data and do not rely on shared existing data.
    • For tests that conflict on resources, use mutual exclusion rules to prevent them from running simultaneously.

    Parameterized Testing

    • Use parameters to run the same test multiple times with different data sets, increasing test coverage and efficiency.
    • Ensure parameterized tests support standard ATF features such as reporting, suites, and data rollback.
    • Copying parameterized tests duplicates all parameters and test data, but note that Custom UI test steps only utilize the first data set for component retrieval.

    Custom UI Testing

    • Test custom UI components like UI pages and macros by retrieving their HTML and JavaScript elements.
    • Use the page inspector tool to identify testable components and their page locations, which assists in distinguishing elements.
    • Navigate to custom UIs using existing test steps, integrating these into your test design.
    • Custom UI testing does not support ServiceNow AI Platform UI (e.g., dashboards, graphical designers); focus on your own custom pages.
    • Override testing properties of page components via specific HTML attributes when needed.
    • When moving tests between instances, manually retrieve page components again since Custom UI test steps do not store component metadata.

    Test Cloning and Execution

    • Clone tests from production to subproduction instances to speed up testing with the most current data.
    • By default, automated tests are disabled on production to avoid accidental runs that could cause data corruption or outages; run tests only on development, test, or non-production environments.

    Warning Messages and Best Practices

    • Impersonating existing users can cause issues; prefer creating new users with appropriate roles and groups.
    • Using system or Application File tables in tests can cause unexpected parallel test behavior; avoid these to maintain test isolation.
    • Avoid using or modifying existing records to ensure tests have expected data states.
    • For server UI actions, always set an appropriate assert type rather than “--None--” and configure timeouts to wait for form submissions to prevent test failures.

    Domain Separation Testing

    • When testing domain-separated data, set the domain explicitly as part of the first impersonation step in each ATF test to ensure correct data context.
    • Follow domain separation recommended practices for service providers to maintain test accuracy and isolation.

    Create reliable, scalable, and efficient tests by following these design considerations.

    General testing

    Avoid modifying ServiceNow system tables or tables extending the Application File [sys_metadata] that can potentially change the behavior of the system. Avoid using or modifying any existing records to prevent unexpected results between tests. The following are some of the common examples of system data changes that can cause unexpected results.
    • Impersonate an existing account
    • Delete an existing record.
    • Run a test that disables a business rule or system property
    • Validate with an existing record

    Parallel testing

    Reduce test design time by running multiple tests and test suites in parallel. Design tests to run in parallel by avoiding resource conflicts and data dependencies.

    Prevent resource conflicts between parallel tests

    Prevent resource conflicts by running tests that create their own data. Tests that run with existing data prevent other tests that need the same data from running in parallel.
    Note:
    If you have two or more resource conflicting tests, see Mark tests as mutually exclusive to create a mutual exclusion rule that prevents them from running in parallel.

    Parameterized testing

    Run a test multiple times with different test data for each run. Create parameters to store test data for each test run. See Parameterized test components for more information.
    • Create parameters to store test data for each test run.
    • Ensure that the parameterized tests support standard Automated Test Framework (ATF) features, such as reports, test suites, and data rollback. Copying a parameterized test copies all parameters, test run data sets, and test steps.
      Note:
      If a parameterized test including Custom UI test steps is created, the system only uses the first data set to retrieve components.

    Custom UI testing

    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.

    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 ServiceNow AI Platform UI
    The Automated Test Framework prevents custom UI testing of ServiceNow AI Platform features. For example, you cannot test dashboards or graphical designers. Instead, build tests to validate your custom UI pages and elements because 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 HTML attributes that are specific to Automated Test Framework. See Override component test actions.
    Retrieve page components again when you move tests to another instance
    Custom UI test steps don’t store UI components as metadata. Testers must manually retrieve page components again when moving tests between instances.

    Clone tests from production system

    Move your tests to the production system to clone the most updated instances for testing. Speed up the testing time by directly copying or cloning a test from the production system to a subproduction instance.

    Note:
    By default, the system property that is used to run automated tests is disabled to prevent you from accidentally running these tests on a production system. To avoid data corruption or an outage, run tests only on development, test, and other non-production instances.

    Warning messages for all testing

    Warning messages Design considerations
    Impersonating an existing user may cause unexpected behavior for this test. Avoid potential issues by adding a 'Create a User' step instead. See the documentation for Test Design Considerations. Create a new user to ensure proper roles and groups and avoid using existing records. See General testing for more information.
    Using a table that extends Application File [sys_metadata] may cause unexpected behavior for other tests running in parallel. See the documentation for Test Design Considerations. Avoid running a test with a table that extends the Application File because it might affect other tests. See Parallel testing for more information.
    Using a system table may cause unexpected behavior for other tests running in parallel. See the documentation for Test Design Considerations. Avoid using a system table because it might affect other tests running in parallel. See Parallel testing for more information.
    Using an existing record may cause unexpected behavior for this test. See the documentation for Test Design Considerations. Avoid using existing records because these records might not have the state and values as expected by the test. Use records created during the test to ensure proper state and values. See General testing for more information.
    Modifying an existing record may cause unexpected behavior for other tests running in parallel. See the documentation for Test Design Considerations. Avoid using existing records because it might affect other tests. Use records created during the test. See General testing for more information.
    Using assert type '--None--' may cause unexpected behavior for server UI actions. Avoid potential issues by setting the assert type and using a timeout. See the documentation for Test Design Considerations. Server UI actions cause the current form to submit and the page to reload. Select an assert type other than None to avoid any unexpected behavior for server UI actions. Set a timeout to ensure that your test waits for the form to be submitted or not submitted before moving on to the next step. When testing server UI actions, the None assert type configures automatically to Form submitted to server.

    Domain separation testing

    When testing domain separation, you must set the domain first. This should be part of the first impersonation step of each of the ATF test steps when they are dependent on a domain being set. To learn more about domain separation recommended practices, see Domain separation recommended practices for service providers.