Allowed client errors
Summarize
Summary of Allowed client errors
The Allowed Client Errors feature in ServiceNow's Automated Test Framework (ATF) enables you to specify known client-side JavaScript errors that should not interrupt test execution. By adding these errors to an allowed list, tests and individual steps can continue running even when these errors occur, helping to maintain test continuity while still tracking issues for future review.
Show less
When to Allow Client Errors
- Timing Constraints: Temporarily allow errors when developers need time to investigate and fix issues, such as legacy bugs in older forms.
- Minimizing Impact of Old Libraries: Ignore client errors from outdated or unimportant libraries to prevent them from affecting test results.
- Test Design Time: Temporarily allow errors caused by recent UI changes until tests are fully developed and errors can be properly analyzed.
- Possible Platform Bugs: Allow errors suspected to be platform bugs while investigating and before reporting to ServiceNow Support.
Important: Allowing client errors does not guarantee test success. It is recommended to investigate these errors to ensure your business processes are not adversely affected.
Report Levels for Allowed Client Errors
The report level controls how the ATF reports occurrences of allowed client errors:
- Warning: Test steps pass with a "Success with warning(s)" status; error messages appear in the test output and logs marked as warnings.
- Ignored: Test steps pass with a "Success" status; errors are logged with an "Ignored" status and do not appear as warnings.
You can change the report level at any time for each allowed client error to adjust how future occurrences are handled.
Matching Process
The framework uses a "contains" search to match client error messages against entries in the Allowed Client Errors table. This means partial matches will allow errors if their message contains the string defined in an allowed error record. Updates to this table automatically propagate to the Client Test Runner.
Managing Allowed Client Errors
- From Test Results: Allow errors while reviewing overall test results.
- From Step Results: Allow errors during detailed step-level result analysis.
- From Test Logs: Review logs and allow errors as needed.
- Manual Entry: Create allowed client error records directly in the Allowed Client Errors table for precise control.
Add known client errors to the allowed client errors list to allow tests and steps to continue running when a specific error occurs. Set the report level to specify what the Automated Test Framework does when the error occurs in future tests.
Scenarios for allowing client errors
Test designers and developers typically allow client-side JavaScript errors to prevent certain types of known failures from impacting test design and results. Scenarios to allow client errors include:
- Timing constraints
- Temporarily allow a client error until your developers have time to investigate and resolve the issue. For example, when testing an old form containing a longstanding bug.
- Minimizing the impact of old libraries
- Ignore client errors that cannot be fixed or are unimportant to your operations to eliminate their impact on future test runs. For example, when you find a bug in an old library.
- Test design time
- Temporarily allow client errors until you finish writing tests and have time to investigate the error. For example, one of your developers modifies a UI policy and the change generates an error.
- Possible platform bug
- Temporarily allow client errors until a fix is available. Prior to reporting a platform bug to ServiceNow Technical Support, investigate the error, verify it is not a customization error, and identify the type of platform bug involved. For example, a UI policy generates an error during a test. Your investigation verifies that the issue is not a customization error and identifies a platform issue with the UI policy.
Report levels for allowed client errors
The report level indicates whether the test framework reports future occurrences of the error as a warning or ignores them altogether. You can change the report level of an allowed error at any time. For example, if you originally add an error as a warning, you can later change the report level to ignored.
| Report level | Description |
|---|---|
| Warning | Test steps containing the allowed client error report a status of Success with warning(s). The error message appears in the test result output, and is recorded in the test logs with the status Warning. |
| Ignored | Test steps containing the allowed client error report a status of Success. The error is recorded in the test logs with an Ignored status. |
Matching process
Identifying and resolving client errors
When client errors occur, the Automated Test Framework fails the test on the step that was executing when the error occurred.