Automated Test Framework design considerations
-
- UpdatedJan 30, 2025
- 4 minutes to read
- Yokohama
- Automated Test Framework
Create reliable, scalable, and efficient tests by following these design considerations.
General testing
- 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
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.
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.