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

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.