Working with client test runners
Summarize
Summary of Working with client test runners
Client test runners in ServiceNow’s Automated Test Framework execute automated test steps involving user-interface (UI) elements such as forms. These tests run within a browser tab or window known as a client test runner. There are two types:
Show less
- Client Test Runners: For manually started tests.
- Scheduled Client Test Runners: For tests triggered by a schedule.
When enabled, the client test runner automatically executes waiting tests in the current browser session and continuously checks every five seconds for new tests to run. It runs tests as the logged-in user unless an impersonation step is included.
Key Features
- Test Execution Property: To use client test runners, the test execution system property must be enabled. By default, it is disabled to prevent unintended test runs in production environments. It is recommended to run tests only in development or non-production instances to avoid data corruption.
- Execution and Debugging Interface: The client test runner interface includes an Execution Frame showing current test activities. If additional debugging is enabled, a Debug Info tab provides extra diagnostic details and captures screenshots linked to test results.
- Browser Recommendations: Some browsers (Internet Explorer, Edge, older Firefox versions) require periodic closure and restart due to memory limitations. To optimize test runs:
- Run the client test runner in a separate browser window.
- Keep the runner window visible and the screen unlocked.
- Set browser zoom to 100% for accurate screenshots.
- Scheduled Suites: On macOS, running scheduled client test runners with Chrome or Safari performs best in a virtual machine where the screen remains active and unlocked. The runner must meet criteria specified in the Scheduled suite run record and be available at the scheduled time.
- JavaScript Window Command Handling: The client test runner intercepts window commands such as
console.log,alert,confirm, andprompt. It provides default responses—e.g.,window.confirmreturns true,window.promptreturns the string "test value", andalertcalls are ignored—ensuring smooth test execution. - Active Test Runners Tracking: When a client test runner starts, it registers in the Active Runners table. Separate modules display manual and scheduled runners. This tracking helps monitor runner status, browser version, and availability. Runners periodically report to the system, and if inactive, they are marked accordingly and eventually removed. Reporting intervals can be customized in the Automated Test Framework properties.
Practical Considerations for ServiceNow Customers
- Enable test execution only in safe environments (development, test instances) to safeguard production data.
- Use the client test runner module to monitor and control test execution, including debugging and viewing live test progress.
- Follow browser best practices to ensure stable and reliable UI test runs, especially when running long or scheduled test suites.
- Leverage the Active Test Runners modules to verify that the appropriate browser and session are available before scheduled tests run.
- Understand how common JavaScript window commands are handled during tests to avoid unexpected test failures.
If an automated test includes steps that involve a form or any other user-interface (UI) element, it runs those steps in a browser tab or window called a test runner or client test runner.
The Automated Test Framework supports two types of client test runners: Client Test Runners for manually started tests and Scheduled Client Test Runners for tests started by a schedule.
When test execution is enabled, clicking the Client Test Runner module opens the client test runner in the current browser session. If tests are waiting to be run, the Client Test Runner runs a waiting test. If no test is running, the message Waiting for a test to run displays in the client test runner.
When the client runner is active, it displays the activity of the currently running test in the Execution Frame.
Test execution property
To work with the client test runner module, the test execution property must be enabled.If the test execution property is disabled when you select this module, the system displays a message and a link to the automated test framework properties page where you can enable it.
Additional debugging functionality
If you have enabled additional debugging functionality, the client test runner module displays two tabs: Execution Frame and Debug Info. The Execution Frame displays the information normally shown by the client test runner and the Debug Info displays additional debugging information.
The system takes screen shots from the tests in the Execution Frame tab and records them to the test result record.
Browser recommendations for all tests and suites
- Some browsers have memory-management limitations that make it necessary to occasionally close and restart the browser when running the client test runner. These browsers include Internet Explorer, Edge, and older versions of Firefox. How often you should close the browser depends on the memory allocation in the browser application.
- Some browsers have features that throttle CPU time. To avoid problems, follow these
guidelines:
- Run the client test runner in its own browser window.
- Keep the client test runner at least partially visible on the screen.
- Make certain the screen is not locked or shut off.
- The client test runner takes screen shots as the tests run. For best results with screen shots, leave the browser zoom level set to 100%.
Browser recommendations for scheduled suites
The client test runners for scheduled suites have additional browser requirements.
- On OS X with the client test runner on Chrome or Safari: If the screen is locked or the client test runner tab is not shown, when the system attempts to run the test suite, tests run significantly slower and may time out. For best performance, run client test runners for scheduled suites in a virtual machine (VM) environment in which the screen does not become locked or disabled.
- The browser must meet the criteria you specified on the Scheduled suite run record.
- A client test runner meeting the criteria you specified on the Scheduled suite run record must be available to run the test suite at the scheduled time. The system cannot automatically open a client test-runner session.
Javascript window command intercepts
The Client Test Runner captures window object commands including console.log, console.error, alert, confirm, and prompt, with default responses where necessary.
- Any script that calls window.confirm receives a boolean response of true.
- Any script that calls window.prompt receives the string response test value.
- Any script call to alert is ignored.
Active Test Runners table
When you start a client test runner, the system registers that runner in the Active Test Runners table. You can view this table in the Active Manual Test Runners module and the Active Scheduled Test Runners module. These two modules provide views of the same table, filtered to show only manual or only scheduled test runners.
The Active Scheduled Test Runner module is useful when you create a scheduled suite run. For scheduled suite runs, you can specify the browser to use. To determine the name and version of a browser you want to use, start a scheduled test runner with that browser, then inspect that runner's record in the Active Scheduled Test Runners module.
The data in this table is transient. While the runner is active, it reports in to the system at a specified interval. If the runner does not report in at the expected time, the system marks the runner as inactive. After a period of time the system deletes the runner. You can modify these intervals on the Automated Test Framework properties page.