Course - Automated Test Framework - ServiceNow Developers

10/28/22, 7:33 AM Course | Automated Test Framework - ServiceNow Developers
Version: Rome
Automated Test Framework

1 MODULE
The Automated Test Framework (ATF) is a ServiceNow application to test

within a ServiceNow instance.
Course Information:
The Automated Test Framework (ATF) is a ServiceNow application to
test within a ServiceNow instance. ATF can be used for regression
testing, test driven development, or other ServiceNow testing
requirements.
Modules
Using the Automated Test Framework

In this module, you will use the Automated Test Framework to
create and run tests and test suites. You will also interpret the
results of the tests.

ARTICLES IN THIS MODULE:
Automated Test Framework Objectives
About This Learning Module
What is the Automated Test Framework?
Tests
https://developer.servicenow.com/print_page.do?release=rome&category=courses&identifier=app_store_learnv2_atf_rome_automated_test_fr… 1/141
Enabling and Running Tests
Viewing Test and Test Step Results
Debugging Tests
Exercise: Run Example Tests
Creating Tests and Adding Test Steps
Exercise: Create a Test
ATF Variables
Using ATF Variables
Exercise: Use an Output Variable
Test Templates
Creating Test Templates
Exercise: Fork Repository and Import Application for the

Using the Automated Test Framework Module
Exercise: Create a Branch for Using the Automated Test

Framework
Exercise: Create a Test Template
Exercise: Create Tests from a Template
Asserting Test Success
Exercise: Assert Test Success
Test Suites
Creating Test Suites
Running Test Suites
Rerunning Test Suites
Exercise: Create and Run a Test Suite
Exercise: Add a Test to the NeedIt App Test Suite
Parameterized Tests
Creating Parameterized Tests
Exercise: Create Parameterized Tests
Scheduling
Create a Schedule
Scheduled Client Test Runners
Scheduled Test Notifications
Exercise: Create and Run a Schedule
Exercise: Save Your Using the Automated Test Framework

Work (Optional)
Test Your Automated Test Framework Knowledge
Using the Automated Test Framework Module Recap
After Completing Using the Automated Test Framework, You

Might Also Be Interested In...
Using the Automated Test

Framework

Objectives
In this module, you will learn to use the Automated Test Framework
(ATF) to:
Create and run tests

Enable running of tests and test suites
Add and configure test steps
Run tests
View and interpret test results
Determine if a client test runner is required for test execution
Use output variables from a test step as input variables in another

test step
Create and use test templates for increased test development
efficiency
Create test suites
Run test suites
View and interpret test suite results
Create schedules for running test suites
Add users to scheduled suite watch lists
Select a browser and/or OS for scheduled suite execution for
suites containing client-side test steps
View and interpret scheduled test suite email reports
About This Learning Module
IMPORTANT: The content in this learning module was last updated for the
Rome ServiceNow release.
Various examples are used on the concept pages in this learning

module. You do not need to attempt to recreate the examples. You will
develop the NeedIt application in the hands-on exercises. Exercises
are indicated in three ways:
Exercise icon in the Navigation pane.

Exercise icon and the word Exercise at the top of the page.
The word Exercise or the word Challenge in the page title.
The NeedIt application allows users to request services from multiple

departments. You will use source control to begin with all NeedIt
application files needed for this learning module.
What is the Automated Test

Framework?
The Automated Test Framework (ATF) is a ServiceNow application
used to automate the testing of applications, customizations, and
configurations.
Test driven development: Testing while developing new

applications
Regression testing: Business logic testing
Regular checkups: Part of routine checks for ServiceNow
Miscellaneous testing: Any other use case where testing is
required
Use ATF to test:
Service Catalog in Service Portal

Forms
Application Navigator
Service Catalog
Custom UI
List and Related List
Forms in Service Portal
REST
Server
Email
Reporting
Responsive Dashboards
For example, before an upgrade, Beth Anglin is able to create records

in the NeedIt table. After an upgrade, use ATF to determine if Beth can
still create NeedIt table records.
Tests
An ATF test is an automated, ordered sequence of steps in
ServiceNow. Steps define the actions to take and the order in which
they execute. ATF executes the steps and reports the status of each
step as well as the overall status of the test.
ATF provides examples of tests for a variety of different actions. To

see the list of sample tests, use the Application Navigator to open
Automated Test Framework (ATF) > Tests.
The Open an Existing Record Test

The Open an Existing Record test is an example test that opens a
record then asserts some values. The steps in the Open an Existing
Record test are:
1. Impersonate the ATF user

2. Open the ATF user form
3. Validate values on the form
ATF takes screenshots of client-side steps. Developers can view the

screenshots when examining test results.
If a user were to manually perform these steps, they would do these

actions:
Step 1 - Impersonate the ATF User
Step 2 - Open the ATF User Form
Step 3 - Verify Values in the User Record Fields
Although it is possible for a user to manually perform the test, ATF

automates test steps, saving time and preventing human errors.
Enabling and Running Tests

ATF tests take action on a ServiceNow instance. To prevent accidental
execution of tests, test execution is disabled by default.
Click the link in a test record to enable running tests, or use the
Application Navigator to open Automated Test Framework (ATF) >
Administration > Properties.

IMPORTANT: As with all testing, run ATF tests only on development or testing
instances. Running ATF in production is neither recommended nor supported.
To execute an ATF test on-demand, open the test record, then click
the Run Test button.

https://developer.servicenow.com/print_page.do?release=rome&category=courses&identifier=app_store_learnv2_atf_rome_automated_test_f… 10/141
If the test steps include client-side actions such as opening a form, the
test executes in a client test runner. A client test runner is the runtime
environment for client-side tests. The client test runner executes the
test steps as a specific user using the browser (for example, Chrome
or Firefox) in which the client test runner is launched.
If desired, watch the test progress in the client test runner.
NOTE: Client tests execute faster when the client test runner is the foreground
window or tab.
When the client test runner finishes executing the current test, it briefly
displays the text Finished text execution, reporting result then returns
to saying Waiting for a test to run. The client test runner remains active
and waits for another test to run. Closing the browser tab terminates
the client test runner. ATF administrators manage client test runners
using the Automated Test Framework (ATF) > Administration > All
Test Runners module.

IMPORTANT: Server-side test steps do not use client test runners.
Monitor the test progress for both client-side and server-side tests in
the ServiceNow window used to launch the test.
After tests execute, ATF rolls back (undoes) data modified during test
execution, except for records in:
History [sys_history_line]
ECC Queue [ecc_queue]
Email [sys_email]
Email Log [sys_email_log]
Report Executions [report_executions]
Report Stats [report_stats]
Any table that extends these tables
NOTE: ATF rollback cannot be disabled. Disabling rollback would have
unintended consequences throughout the platform and is not allowed.
Viewing Test and Test Step

Results
When execution is complete, click the Go to Result button to view the
step-by-step test results. To review past test results, use the
Application Navigator to open Automated Test Framework (ATF) >
Test Results.

The test results record displays the test result, test step results, test
log, and transactions involved in executing the test.

The possible test step status values are:
Waiting: has not run yet

Running: currently executing
Success: completed successfully
Failure: completed but the result was not successful
Skipped: was not ran, typically due to a failure in a prior step
Error: was not completed due to an error during execution
Canceled: was not executed due to user intervention
Screenshots
If enabled, screenshots are captured during test execution and
attached to the test result record. This property is enabled by default.
To change the property's value, use the Application Navigator to open
Automated Test Framework (ATF) > Administration > Properties.
Click the [download] link in the test result record to download and
view a screenshot.

To download all screenshots for viewing, click the Manage

Attachments link and click the Download All button.
Test Steps
Use the Step Results related list to view the results for a specific test
step. Click the link in the Start time column to open the Test Step
record.

For example, clicking the link for the Impersonate step result opens
the impersonate step result record.

Test Log
Use the Test Log related list to see the logging information for the test
and all test steps.

Test Transactions
Use the Test Transactions related list to view the transactions for the
test steps. The transactions shown here are browser (client-side)
interactions with ServiceNow.

Debugging Tests
ATF provides debugging to allow developers access to additional

information about test execution.
Debugging is disabled by default. To enable test debugging, open

Automated Test Framework (ATF) > Administration > Properties.
Select the Enables additional debugging functionality check box.
Enabling debugging adds a Debug Info tab to client test runners.

Debugging writes information to the test record's Test Log.

When debugging is enabled, ATF logs more detailed test execution

behavior to the Test Log. Notice the Open an Existing Record's Test
Log contains more statements when debugging is enabled.
Exercise: Run Example Tests
In this exercise, you will run two example ATF tests: Simple UI Test
and Fails Because no Form is Open. You will also examine the test
results.
NOTE: If your PDI automatically opens App Engine Studio, you need to
change the user role used to access the PDI. To complete the exercises,
switch to the Admin user role
(https://developer.servicenow.com/dev.do#!/guides/rome/developer-program/pdi-
guide/managing-your-pdi#changing-your-instance-user-role).
Preparation
1. Use the Application Navigator to open User Administration >
Users.
2. If the column search row is not already visible, click the Show
column search row icon ( ).

3. Type *chad in the Name field search field and press the <return>
(enter) key on your keyboard.

4. Verify there is not a user record for a user named Chad

Chaddington.
Perform the Run Simple UI Test Steps Manually
1. Use the Application Navigator to open Automated Test

Framework (ATF) > Tests.
2. Locate the Simple UI Test test and open it for editing.
3. Scroll to the Test Steps related list. Examine the six steps to make
sure you understand what they test.
4. Execute the test steps manually to see what the test does and get
a sense of the time savings from using ATF.
1. Start a timer using a clock, phone, or online timer

(https://www.online-stopwatch.com/full-screen-stopwatch/).
2. Impersonate Fred Luddy.

1. In the main ServiceNow browser window, open the User
menu by clicking your user name in the ServiceNow
banner. Select the Impersonate User option.
2. In the Search for user field, type Fred.

3. In the drop-down list, click fred.luddy.
4. Examine the User menu in the ServiceNow banner. You
should now be Fred Luddy.
3. Create a User record.

1. Use the Application Navigator to open User
Administration > Users.
2. Click the New button.
3. If you are able to capture screenshots, take a
screenshot of the new User form.
4. Set field values in the new User record.
User ID: test.testing
First name: Test
Last name: Testing
Email: test.testing@example.com
5. If you are able to capture screenshots, take a screenshot of
the Test Testing user form.
6. Validate field states: visible, read-only, mandatory.
1. The Email field should be visible on the form.
2. The City field should NOT be visible on the form.
3. You should be able to write to (change the values in) the
Active and Password needs reset fields.
4. The User ID, Email, and First Name fields should not be
mandatory. Recall that mandatory fields are preceded by
an asterisk.
5. If you are able to capture screenshots, take a
screenshot of the form.
7. Click the Submit button.
8. Re-open the Test Testing user form from the list.
9. If you are able to capture screenshots, take a screenshot of
the Test Testing User form.
10. Roll back the test steps by deleting the test.testing user
record and returning to the admin user.
1. On the Test Testing user record form, click the Delete
button.
2. In the delete Confirmation dialog, click the Delete
button.
3. Open the User menu by clicking Fred Luddy in the
banner and select the End Impersonation menu item.
5. Stop the timer. Note how long it took to complete the test steps.
Run the Simple UI Test - ATF
1. If not already in the Global scope, switch to the Global scope.
1. If you have added the Application picker to the ServiceNow

banner, use the Application picker to change the scope to
Global.
2. If you have not added the Application picker to the

ServiceNow banner:
1. Click the Settings button ( ) in the ServiceNow banner.

2. Select the Developer pane then use the Application
field to change the scope to Global.
3. To add the Application picker to the ServiceNow banner,
enable the Show application picker in header toggle
(optional).
4. Close the System Settings dialog.

3. Locate the Simple UI Test test and open it for editing.
4. Click the Enable tests and test suites here link. If you have
already enabled running tests, you are not prompted again.
5. Enable test/test suite execution by clicking to place a check mark

in the Yes | No box.
6. Click the Save button.
7. Return to the Simple UI Test record.
8. Execute the test.
1. Click the Run Test button.

2. In the Pick a Browser dialog, make sure the Start a new test
runner option is selected, then click the Run Test button.
3. Watch the client test runner as the test steps execute. When
the test steps finish and the client test runner says Waiting
for a test to run, return to the browser tab where the Simple
UI Test is open.

9. Examine the Run Test dialog.
1. The Run Test dialog should indicate that all steps were
successful.
2. Click the Go to Result button.
10. Examine the Simple UI Test results record.
1. How does the value in the Duration field compare to how

long it took you to complete the Simple UI Test steps
manually?
2. Scroll to the Step Results related list. All six steps should
have completed successfully.
3. Open the Test Log related list and scroll through the logging
information.
4. Open the Test Transactions related list to see what
interactions the test steps had with the browser.
5. View the screenshots captured by the test.
1. At the top of the Simple UI Test results form, click the

Manage Attachments link.
2. Click the Download All button.
3. Use the application of your choice to view the
downloaded screenshot files.
11. Use the Application Navigator to open User Administration >

Users and look for a user record for Chad Chaddington.
QUESTION: Is there a user record for Chad Chaddington? Should

there be?
ANSWER: ATF cleaned up after itself when the test finished

executing. The Chad Chaddington record created during the test was
deleted from the User table when the test finished execution.
Run the Fails Because no Form is Open Test

1. Open the Fails Because no Form is Open example test.
2. Examine the test to see what it does.
3. Read the Description field value to see why the test fails.
5. If the client test runner is still open from the last test, you should
see it listed in the Pick a Browser dialog. Click the Run Test
button.
6. When the test finishes, examine the results. Use the test results to
determine why the test failed. Is this what you expected based on
the Description field in the test?
Creating Tests and Adding Test

Steps
To create a test, use the Application Navigator to open Automated
Test Framework (ATF) > Tests. Click the New button.
Configure the test record.

Name: Enter a descriptive name for the test.

Active: The test is available in the runtime environment.
Enable parameterized testing: Enable the test to run with
parameterized values. This topic is covered in more detail later in
this module.
Description: Describe what the test does.
DEVELOPER TIP: Include the expected test outcome in the Description field.
Your colleagues and your future self will appreciate it.
Click the Save button. The form displays the Test Steps, Test Results,
and Mutually Exclusive Tests related lists.

Adding Test Steps

In the Test Steps related list, click the Add Test Step button. In the
Add Test Step dialog, select a test category:
All Steps: Uncategorized list of all steps

Custom UI (https://docs.servicenow.com/bundle/rome-application-
development/page/administer/auto-test-framework/reference/test-steps-
custom-ui-category.html)
List and Related List (https://docs.servicenow.com/bundle/rome-
application-development/page/administer/auto-test-
framework/reference/test-steps-list-related-list.html#test-steps-list-
related-list)
Service Catalog (https://docs.servicenow.com/bundle/rome-application-
service-catalog-category.html)
Forms in Service Portal (https://docs.servicenow.com/bundle/rome-
framework/reference/test-steps-forms-portal-category.html)
Application Navigator (https://docs.servicenow.com/bundle/rome-
framework/reference/test-steps-app-navigator-category.html)
Service Catalog in Service Portal
(https://docs.servicenow.com/bundle/rome-application-
catalog-portal-category.html)
Form (https://docs.servicenow.com/bundle/rome-application-
form-category.html)
REST (https://docs.servicenow.com/bundle/rome-application-
rest-category.html)
Responsive Dashboards
Email (https://docs.servicenow.com/bundle/rome-application-
email-category.html#test-steps-email-category)
Reporting
Server (https://docs.servicenow.com/bundle/rome-application-
server-category.html)
Select a test step to add to the test then click the Next button.
In the Add Test Step dialog, configure the step. The step fields depend
on the selected test.
Click the Submit button.
Execution Order
The execution order determines the order in which test steps execute.
By default, the order is the order in which the steps are added to the
test.
While Creating Test Steps
When adding test steps to a test, use the Insert after choice list to
place the step in the desired location.

After Creating Test Steps
After creating test steps, use the Execution order field to renumber the
step that is out of order. Save the form and the other test steps are
automatically re-ordered based on the change you made.
DEVELOPER TIP: Many tests start with a Create a User or an Impersonate
test step to make sure the test steps work as expected for users other than an
administrator.
Exercise: Create a Test

In this exercise, you will create and run a test that:
Opens an existing Incident table record

Validates the Short description field contains the string email
Verifies the Update button (UI Action) is visible
Preparation
1. Use the Application Navigator to open Incident > Open.
2. If the column search row is not already visible, click the Show
column search row icon ( ).

3. Type *email in the Short description field search field and press
the <return> (enter) key on your keyboard.

4. Make a note of the INC Number for an email incident.
Create a Test
3. Configure the test:
Name: Validate Email Incident
Description: Open existing Incident record, validate the
Short description contains the string email, and verify
the Update button is visible.
Add the Open an Existing Record Test Step

1. In the Test Steps related list, click the Add Test Step button.
2. In the Add Test Step dialog, select the Form category.
3. Select the Open an Existing Record test.
4. Read the test step explanation to understand what the test step
does.
5. Click the Next button.

6. Select the Table for the test step:
Table: Incident [incident]
7. Configure the Record for the test step.
1. Click the Lookup documents using list button ( ) in the

Record field.
2. Click the Lookup using list button ( ) for the Document

field.
3. Build a filter to find active incidents for email issues.
1. Click the Filter button ( ) to open the Filter Builder.
2. Configure a filter condition: [Active] [is] [true]

3. Click the AND button and configure another filter
condition: [Short description] [contains] [email]
4. Click the Run button to apply the filter to the Incident list.
4. Choose a record from the filtered list by clicking a record
number.
5. Click the OK button.
8. Read the annotation for the Record field.
QUESTION: What does the annotation mean?

ANSWER: Automated Test Framework cannot guarantee that a

specific record exists on an instance. If the selected record is deleted,
the test will fail. The annotation reminds the developer to be aware that
the selection of an existing record could cause unexpected results.

Add the Field Values Validation Test Step
3. Select the Field Values Validation test step.
does.
6. Configure the Conditions for the test step:
Conditions: [Short description] [contains] [email]

NOTE: The Field Values Validation test step is case sensitive.
Depending on the values in your incidents, you may need to adjust your
Conditions to validate successfully.
Add the UI Action Visibility Test Step

3. Select the UI Action Visibility test.
does.

6. Configure the Visible field for the test step to verify the Update
button is visible:
1. Click the Unlock Visible button ( ) for the Visible field.
2. Click the Lookup using list button ( ).

3. Use the Filter Builder to add two conditions: [Name]
[contains] [Update] and [Condition] [is not empty].
4. Click the Run button.
5. The filter should return one result. Select the record to add it
to the list of UI Actions which should be visible on the form
during the test step.

Run the Validate Email Incident Test
1. Execute the Validate Email Incident test.

2. In the Pick a Browser dialog, start a new test runner or use
an existing one if open.
4. Watch the client test runner as the test steps execute. When
the test steps finish and the client test runner displays the
text Waiting for a test to run, return to the browser tab where
the Validate Email Incident test is open.

successful.
3. Examine the Validate Email Incident test results record.
1. Scroll to the Step Results related list. All three steps should
have completed successfully.
NOTE: If the Field Values Validation test step failed, it may be due
to the test step being case sensitive. The Field Values Validation
test step Conditions contains [Short description] [contains] [email]
where email is lowercase. Email may be capitalized in the Incident
record's Short description. So, you may need to adjust your
Conditions to validate successfully.
2. Open the Test Log related list and scroll through the logging
information.
3. Open the Test Transactions related list to see what

interactions the test steps had with the browser.
1. At the top of the test results form, click the Manage

Attachments link.
3. Use the application of your choice to view the
downloaded screenshot files.
Challenge
Modify the Validate Email Incident test so it executes all test steps as
a user with the admin role. Run the test and examine the results to
make sure the test is still successful. If you get stuck, you can view the
challenge solution.
CHALLENGE SOLUTION:
The first step in the Validate Email Incident test should be to Create a
User. The user can have any name. The user should be configured
with the admin role and the Impersonate this user field should be
Selected (checked).
More Test Cases

If you are interested in seeing more test cases for ATF, visit the
Automated Test Framework use case examples
(https://docs.servicenow.com/bundle/rome-application-
development/page/administer/auto-test-framework/concept/atf-use-
cases.html) page on the docs.servicenow.com site.
ATF Variables
ATF uses variables to pass data from one test step to another. There
are two types of variables:
Input
Output
Input Variables
Input variables provide test steps with the information they need to
run. Developers provide values for input variables when configuring a
test step. For example, the Create a User test step has five input
variables: First name, Last name, Roles, Groups, and Impersonate
this user.

Output Variables
Some test steps return values, known as output variables. Output

variables can be used as inputs to later test steps. For example, the
Create a User test step outputs a user variable other test steps can
use.
Using ATF Variables

When configuring tests, developers can use output variables from
earlier test steps to populate input variables in subsequent test steps.
In the example, User is an output variable from the Create a User test
step. Any test step that occurs after the Create a User test step can
use the User output variable to populate its input variables.

Test step fields that accept output variables as their input have a Data
Pill Picker button.

The Data Pill Picker button opens a list of steps with output variables
available for use with input variables.

Click a step to open a list of output variables from that step.
Click an output variable in the right-hand column to insert it into the

input variable.
The visual representation of a variable is a data pill. The syntax shown

in the Caller field means from test Step 1: Create a User, use the
output variable User as the input to the Caller field.
This training module uses the convention (Step ➔ Variable) to denote

data pills.
Dot-walking
The User output variable is a reference (sys_id) that uniquely identifies

a record in the database. To use a field value from the reference
record to populate an input variable, click the Expand button ( ) then

select the field of choice. Using references, developers can dot-walk
through related records.
Exercise: Use an Output Variable

In this exercise, you will modify the Validate Email Incident test by
adding a Set Field Value test step. The new test step uses an output
variable to populate an input variable.
Add a Test Step to the Validate Email Incident

Test
1. If not still open from the last exercise, open the Validate Email
Incident test for editing.
2. Locate the Validate Email Incident test in the list and open it
for editing.
2. Add a Set Field Values test step after the existing Field Values
Validation test step.
2. In the Insert after choice list, select the Step 3 - Field Values
Validation test step.
3. In the categories pane, select the Form category.
4. In the test steps pane, select Set Field Values.
3. Set the Caller field value to the User output variable from the
Create a User step.
1. Click the Data Pill Picker button ( ) for the Caller field.
2. Click Step 1: Create a User.
3. Click User.
4. Examine the syntax in the Caller field to make sure you
understand it.
5. Click the Delete button ( ) for any other fields listed so

only the Caller field is set.
4. Click the Additional Actions menu ( ) and select the Save

menu item.
5. In the Test Steps related list, examine the Description field for the
Set Field Values test, paying particular attention to how the Caller
field value is set.
Run the Validate Email Incident Test
1. Execute the Validate Email Incident test.

2. In the Pick a Browser dialog, start a new test runner or use
an existing one if open.
4. Watch the Client Test Runner as the test steps execute.
When the test steps finish and the Client Test Runner says
Waiting for a test to run, return to the browser tab where the
Validate Email Incident test is open.
successful.
3. Examine the Validate Email Incident test results record.
1. Scroll to the Step Results related list. All steps should have
completed successfully.
2. Examine the summary for the Set Field Values test to verify
the caller_id field value matches the user created in test step
1.
1. At the top of the test results form, click the Manage

Attachments link.
3. Use the application of your choice to view the downloaded
screenshot files. In the third and fourth screenshots, the
Caller should be what you named the user you created.
Test Templates
An ATF test template is a reusable set of test steps that are commonly
used together. Test Templates can include any combination of test
steps. A template's test steps may require additional configuration
once added to a test.
ATF includes a Default New Form Test Template as an example. The

default template includes a sequence of eight test steps.

To add a test template to a test, click the Add Test Template button in
the Test Steps related list for a test. Select a template. If prompted,
provide other variable values. Variable values requested depend on
the test steps in the template. Click the Add button.

The template populates the Description field based on the test steps
from the template. The description includes instructions to the
developer explaining what must be done to the template's test steps to
make the template steps work. If the Description field had a value
before the template was added to the test, the template steps and
instructions are appended to the existing Description field value.
The template's test steps are added to the Test Steps related list. Edit
and delete steps added from a template using the same strategies
used for individually added test steps. For example, if only six of the
eight test steps added by a template are required for a test, a
developer can add the test steps using a template, then delete the
unnecessary test steps from the test. In the example, the test does not
need to verify UI Action Visibility. The UI Action-related test steps can
be deleted without deleting all test steps added by a template.
Creating Test Templates

ATF administrators create and edit test templates using the
Automated Test Framework (ATF) > Administration > Test
Templates module.

Name: Descriptive name for the template's collection of test

steps. For example, Create and Test Forms.
Test template: Ordered list of test steps.
Description: Add text describing the intended use of the
template. The Description on the template does not appear in the
Description field on tests using the template.
Adding Test Steps

To add test steps to a template, click the Unlock Test template button
( ) then edit the test steps list.

To add test steps using the slushbucket, select a test then click the
Add button ( ). Click the Save button when done.

Exercise: Fork Repository and

Import Application for the Using
the Automated Test Framework
Module
ServiceNow uses GitHub to provide application repositories to copy
and use with the Developer Site learning content. The repositories
contain tags, which are fixed sets of application files, to start you with
a partially built application. By copying and importing a ServiceNow-
provided repository into your Personal Developer Instance (PDI), you
get all the files needed for the hands-on exercises in the modules.
NOTE: See the GitHub Guide (/dev.do#!/guide/rome/now-platform/github-
guide/github-and-the-developer-site-training-guide-introduction) for more information
on how ServiceNow uses GitHub with the Developer Program learning content
and to see a video on how to fork a repository and import an application.
In this exercise, you will:
1. Fork the ServiceNow repository to your GitHub account.

2. Import the application into your PDI from your fork of the
repository.
IMPORTANT: If you have already forked and imported the repository, you can
proceed to the next exercise, where you will create a branch from a tag to load
the application files to your PDI. The NeedIt application files are needed to
complete the module.
Fork the Repository

In this section of the exercise, you will create a personal fork of the
application repository to use with Developer Site learning content.
1. In a web browser, open github.com (https://github.com/).

2. If you have a GitHub account, sign in. If not, sign up for a new
account.
3. Once signed in, open the NeedIt repository
(https://github.com/ServiceNow/devtraining-needit-rome).
4. Click the Fork button ( ) to create a copy of the repository

in your GitHub account.
5. On the Create a new fork page, deselect the Copy the main
branch only option.
6. Select your personal GitHub account as the fork Owner, then click
the Create fork button.
7. Verify the URL for your fork of the repository is similar to:
<YourGitHubUsername>/devtraining-application-release.
8. Copy the forked repository's URL.
1. Click the Code button.
2. Make sure the URL contains your GitHub username, not

ServiceNow.
3. Make sure HTTPS is selected. If not, select the HTTPS tab

in the Clone flyout.
4. Click the Copy to clipboard button ( ).
NOTE: You will use the copied URL to configure the connection to
your forked repository in the next section.
Import the Application from the Forked

Repository
In this section of the exercise, you will import the application repository
into ServiceNow. As part of the process, you will first create a
Credential record for your GitHub account, then you will use Studio to
import the application repository into your PDI.
1. Log in to your PDI as the admin user. If you do not have a PDI,
open the ServiceNow Developer Site
(https://developer.servicenow.com) to obtain a Rome PDI.
NOTE: See the Personal Developer Instance (PDI) Guide
(/dev.do#!/guide/rome/now-platform/pdi-guide/personal-developer-instance-
guide-introduction) for instructions on how to obtain a PDI.
2. Create a Credential record for the GitHub connection.
IMPORTANT: Credential records only need to be created once. If you
have already created a credential record in another exercise, please
skip this step.
1. Use the Application Navigator to open Connections &

Credentials > Credential.
3. In the What type of Credentials would you like to create? list,

click the Basic Auth Credentials link.
4. Configure the Credential record.
Name: GitHub Credentials - <Your github.com

Username>
User name: <Your github.com Username>
Password: <Your github.com personal access token>
IMPORTANT: GitHub requires personal access tokens to access
repositories from other platforms, like ServiceNow. A personal
access token is used in place of a password when
authenticating. See the Authenticating to GitHub
(/dev.do#!/guides/rome/developer-program/github-guide/using-
servicenow-provided-application-repositories#authenticating-to-github)
section of the GitHub Guide for instructions on how to create a
GitHub personal access token.
3. Use the Application Navigator to open System Applications >

Studio.
4. Studio opens in a new browser tab.
5. In the Select Application dialog, click the Import From Source

Control button.
6. In the Import Application dialog, configure the connection to the

forked repository.
URL: <URL you copied for your forked version of the

repository>
Credential: GitHub Credentials - <Your github.com
Username>
Branch: main
NOTE: When you change the Branch value to main, an information
message informs you that Use of the default naming convention is
strongly encouraged. The value in the Branch field must exist in the
repository. The Developer Site training repositories all have a main
branch, which should be used in place of the default value.
7. Click the Import button.
8. When the application import is complete, click the Select

Application button.
NOTE: If the connection fails, you may have entered the ServiceNow
repository URL in the URL field instead of the forked repository URL, or
you may have enabled two-factor authentication on your GitHub
account. See Troubleshooting GitHub Issues (/dev.do#!/guide/rome/now-
platform/github-guide/troubleshooting-github-issues) for instructions on how
to troubleshoot the connection.
9. In the Select Application dialog, click the application to open it for

editing in Studio.
IMPORTANT: You will not see any application files in Studio until you
successfully create a branch from a tag in the next exercise.
Exercise: Create a Branch for

Framework
In this exercise, you will create a branch of the NeedIt application for
the Using the Automated Test Framework module that includes the
application files used in the module.
NOTE: Before you begin this exercise, you need to have forked and imported
the NeedIt repository as described in Exercise: Fork Repository and Import
Application for the Using the Automated Test Framework Module.
1. If the NeedIt application is not open in Studio from the previous

exercise, open it now.
1. In the main ServiceNow browser window, use the Application

Navigator to open System Applications > Studio.
2. In the Select Application dialog, click the NeedIt application.
2. In Studio, open the Source Control menu and select the Create
Branch menu item.
3. Configure the branch.
Branch Name: ATFModule
Create from Tag: LoadForATFModule
4. Click the Create Branch button.
5. Click the Close button.
6. To load the application files included in the tag, return to the main
ServiceNow browser tab (not Studio) and click the browser's
reload button to refresh the page.
NOTE: If branch creation fails, you may have entered the ServiceNow
repository URL in the URL field instead of the forked repository URL, or
you may have enabled two-factor authentication on your GitHub
account. See the Troubleshooting GitHub Issues
(/dev.do#!/guide/rome/now-platform/github-guide/troubleshooting-github-issues)
section of the GitHub Guide for instructions on how to troubleshoot
GitHub connection issues.
Exercise: Create a Test Template

In this exercise, you will create a test template to use in the next
exercise. When an instance is upgraded, you may want to do
regression testing on the NeedIt When needed field date Business
Rule to make sure it works in three cases:
Past
Today
Future
You will create a template to test Business Rules.
Preparation
1. If not still open from the last exercise, open the NeedIt application
in Studio for editing.

2. In the Select Application dialog, click the NeedIt application
to open it in Studio.
2. In Studio, use the Application Explorer to open Server

Development > Business Rules > NeedIt When needed field
date past.
3. To understand what the Business Rule does, examine the NeedIt

When needed field date past logic.
1. To determine which records the Business Rule is for,

examine the Table field value.
2. Use the When to run section (tab) to determine which
database interaction(s) (Insert, Update, Delete, Query)
trigger the Business Rule and what conditions must be met
for the Business Rule to execute.
3. Switch to the Advanced tab and read through the script to
see what it does.
QUESTION: What does the NeedIt When needed field date past
Business Rule script do?
ANSWER: When a user attempts to create a record with a When

needed value in the past, the Business Rule displays an error
message to the user and does not save the record to the
database.
4. Open and examine the NeedIt When needed field date today
Business Rule to understand when the Business Rule will trigger
and what happens when it triggers.
5. Create a NeedIt record.
1. Return to the main ServiceNow browser window and use the

Application Navigator to open NeedIt > Create New. If the
NeedIt Application is not available, reload the page in the
browser.
2. On the form, notice which fields are mandatory. Do all of the
mandatory fields have values? Make a mental note of which
mandatory fields have default values. You need this
information for the next exercise.
3. Set the When needed field value to a date in the past.
1. In the When needed field, click the Select date and
time button ( ).
2. Set the date to yesterday or any date older than
yesterday.
3. Click the Submit button. Was the record saved to the

database? Based on what you know about the NeedIt
When needed field date past Business Rule, is this the
expected behavior?
4. Set the When needed field value to today's date.
time button ( ).
2. Set the date to today.
database? Based on what you know about the NeedIt
When needed field date today Business Rule, is this the
expected behavior?
5. Set the When needed field value to a future date.
time button ( ).
2. Set the date to a date in the future but not on today.
database? Based on what you know about the Business
Rules for the NeedIt table, is this the expected
behavior?
Create a Test Template

Navigator to open Automated Test Framework (ATF) >
Administration > Test Templates.
3. Configure the test template:
Name: Business Rule Test - NeedIt

Description: Create a user, insert a record, verify all
mandatory fields have values, log results
4. Save the record by clicking the Additional actions menu ( )

and selecting the Save menu item.
5. Add test steps to the Test template field.
1. Click Unlock Test template button ( ).
2. Add the Create a User test step using the Search field.
1. In the Search field, type create.

2. Select the Create a User test step from the choice list.
3. Use the Search field to add additional test steps to the

template.
Record Insert
Record Validation
Log
100%;"/>
6. Click the Update button.
7. You will use and test the template in the next exercise.
Exercise: Create Tests from a

Template
In this exercise, you will use the test template you created in the last
exercise to create three tests for new NeedIt records. All three tests
will:
Create a User
Insert a Record
Validate a Record
Log the test
In addition, each of the three tests will set a date in the When needed
field. The dates will be different in each of the tests.
Past
Today
Future
Preparation
The tests you create are part of the NeedIt application. Make sure
NeedIt is the current scope.
1. In the main ServiceNow browser window, click the Settings
button ( ).
2. Open the Developer pane.
3. Use the Application field to verify the current application is NeedIt.
4. If you would like, set the Show application picker in header toggle
to Selected (green) to display the current application in the
ServiceNow header.
Create a Test - Future

Navigator to open Automated Test Framework (ATF) > Tests.
Name: When needed - Future
5. Add a test template.
1. In the Test Steps related list, click the Add Test Template
button.
2. Select and configure the test template.
Template: Business Rule Test - NeedIt
Table: NeedIt
3. Click the Add button.
6. In the test, examine the Description field. The test template

created the Description field text.
7. Configure the Create a User test step.
1. In the Test Steps related list, click the Create a User link.
2. Configure the test step variables.
First name: Jodie
Last name: Whittaker
Roles: admin
Impersonate this user: Selected (checked)
8. Configure the Record Insert test step.
1. In the Test Steps related list, click the Record Insert link.
2. Set the When needed field value.
1. Click the Choose date button ( ).

2. Set the When needed field value to <select any date in
the future>.
3. Click the Save (Enter) button.
3. Set the Requested for field value.
1. Click the Data Pill Picker ( ) button for the

Requested for field.
3. Click the User reference.
4. Set the Requested for email field value to First name.Last

name@example.com.
1. Click the Data Pill Picker ( ) button for the

Requested for email field.
3. Click the Expand ( ) button for the User reference.

4. Select the First name field.
5. Type a period.
6. Add the (Step 1: Create a User ➔ User ➔ Last name)
data pill.
7. Type @example.com to complete the email address.
5. Delete the Request type and What needed fields by clicking

the Delete button for each of the fields.

QUESTION: Why did you set a value for the When needed,
Requested for, and Requested for email fields and not for the
Request type and What needed fields?

ANSWER: Requested for and Requested for email do not have

default values, but Client scripts populate these fields when you
open the form. The Request type and What needed fields on the
NeedIt form have default values. If you leave the Request type
and What needed fields in the test with blank values, the test will
use null when executing instead of the default values.

9. Configure the Record Validation test step.
1. In the Test Steps related list, click the Record Validation

link.
2. Click the Data Pill Picker ( ) button for the Record field.
3. Click Step 2: Record Insert.
4. Click Record.
5. Configure the field values to validate.
[Requested for] [is] [(Step 1: Create a User ➔ User)]
[Requested for email] [is] [(Step 1: Create a User ➔
User ➔ First name).(Step 1: Create a User ➔ User ➔
Last name)@example.com]
[Request type] [is] [Legal]
[What needed] [is] [Legal 1]
[When needed] [is not empty]
100%;"/>
10. Configure the Log test step.
1. In the Test Steps related list, click the Log link.
2. In the Log field, enter the text Test of When needed with a
date in the future should succeed. Record inserted by
test: (include a space after the colon).
3. Click the Data Pill Picker ( ) button for the Log field and
select (Step 2: Record Insert ➔ Record).
Testing
QUESTION: Why does this test not prompt you to select a Client
Test Runner?

ANSWER: All test steps in this test are server based and do not
require a Client Test Runner.

2. Examine the Run Test dialog. The test should have passed.
4. Examine the Step Results related list. All test steps should have a
status of Success.
Improving the When Needed - Future Test

You may have noticed the When needed date was hard-coded into the
test. This means the test must be manually modified when you want to
run it. Instead of hardcoding the date, set the date dynamically using
server-side JavaScript.

2. Open the When needed - Future test for editing.
3. In the Test Steps related list, click the Record Insert test step to
open it for editing.
4. If you are unfamiliar with the GlideSystem daysAgo() method

(https://developer.servicenow.com/app.do#!/api_doc?
v=rome&id=SGSYS-daysAgo_N), read about it in the server-side API
documentation.
5. Set the value of the When needed field dynamically:
When needed: javascript:gs.daysAgo(-3)
QUESTION: Why do you pass a negative number to the method

for the date?

ANSWER: The method contains the word "Ago" which means in

the past. Passing a positive number to the method says how long
in the past. For example, gs.daysAgo(3) means three days in the
past. Passing a negative number to an Ago method means the
future. For example, gs.daysAgo(-3) means three days in the
future.

7. Using the same techniques as earlier in this exercise, run the

When needed - Future test again and examine the test results. All
test steps should be successful.
Challenge - Past and Today
DEVELOPER TIP: You may find the Copy Test button on the When needed -
Future test form useful for this Challenge.
QUESTION: Based on the testing you did in the last exercise, will the
user be able to save a NeedIt record with a When needed date in the
past?

ANSWER: The NeedIt When needed field date Business Rule

prevents new NeedIt records from being saved if the When needed
field date value is today#singleQuotes date or in the past. New NeedIt
records must have a When needed date in the future.

Using the When needed - Future test as an example, create two more
tests:
When needed - Past

This test should be identical to the When needed - Future
test, except it tests a When needed field value that is in the
past
When needed date is in the past: javascript:gs.daysAgo(3)
The Record Insert test step should fail.
Update the Log test step to indicate that the test is expected
to fail.
When needed - Today
This test should be identical to the When needed - Past test,
except it tests a When needed field value that is today
When needed date is today: javascript:gs.minutesAgo(-20)
The Record Insert test step should fail.
Update the Log test step to indicate that the test is expected
to fail.
After creating the two tests, run them to make sure you get the
expected results. Both tests should fail.
QUESTION: Why are the When needed - Past and When needed -
Today tests expected to fail?
ANSWER: The Business Rule NeedIt When needed field date verifies
that the When needed date is in the future. If the When needed date is
not in the future, the Business Rule prevents the record insert. The
When needed - Past and When needed - Today tests should fail to
insert the record when the Business Rule is working. The Record
Insert test step fails.
Asserting Test Success

In the last exercise, the When needed – Past test failed because the
NeedIt When needed field date Business Rule prevented a new record
from being saved. Although the test failed, failure was the expected
outcome. Since failure was the expected result, one could say that the
test step was successful. When creating tests for applications,
developers are able to define the success criteria for some test steps.
Use the Assert type field to specify the success criteria for a test step.
For example, the Assert type choices for the Record Insert test step
are:
Record successfully inserted: The test step is successful if the

record is inserted.
Record was not inserted: The test step is successful if the
record is NOT inserted.

Different test steps have different Assert type field values. The Record
Query test step has different Assert type values than the Record Insert
test step.
There is at least one record matching the query: The test step
is successful if the query returns one or more records.
No records match the query: The test step is successful if the
query does not find any matching records.
Assert options for test steps (https://docs.servicenow.com/bundle/rome-

application-development/page/administer/auto-test-framework/reference/test-
steps-server-category.html#test-steps-server-category) are available on the
ServiceNow Docs site.
DEVELOPER TIP: Set the Assert type to match the expected outcome for the
test step so tests succeed when they match the expected outcome.
Exercise: Assert Test Success

In this exercise, you will update the When needed - Past and When
needed - Today tests to report success instead of failure when the
NeedIt record is not created. The When needed - Past and When
needed - Today tests expect the record creation to fail when the
NeedIt When needed field date Business Rules works properly. To
report success, you will set the Assert type for the Record Insert test
step to assert that record creation failure is expected.
Update the When needed - Past Test

2. Open the When needed - Past test for editing.
3. Update the Record Insert test step.
1. In the Test Steps related list, click the Record Insert test
step to open it for editing.
2. Set the Assert type field to Record was not inserted.

4. Delete the Record Validation and Log test steps.
QUESTION: Why did you delete the Record Validation and Log test
steps?
ANSWER: The Record Validation test step can be deleted because no

record is inserted in the When needed - Past test to validate. The Log
note indicating failure is expected is no longer required because the
Assert type has been configured on the Record Insert to succeed
when the record cannot be inserted.
Test the When needed - Past Test

2. Examine the Run Test dialog. The test should have succeeded.
4. Examine the Step Results related list. Note the information
included in the Summary for the Record Insert test step.
Challenge
Update the When needed - Today test to succeed if the recorded is
created:
When needed - Today

Modify the Record Insert test step configuration so the test
step is successful if the record is inserted.
Remove the Record Validation and Log test steps.
Run the test to be sure the test completes successfully.
Test Suites
Test suites are hierarchical, logical groupings of related tests and/or

other test suites to run as a single job. For example, the tests created
in the last exercise are related because they test the three cases
handled by the same Business Rule. In the exercise, the tests were
ran individually but it makes more sense to run them as part of the
same group.
A test suite that runs the three tests created in the last exercise might
have a hierarchy like this:
In this example, the test suite NeedIt App Test Suite is a hierarchy of
tests and test suites.

The top-most level is NeedIt App Test Suite. The remaining tests and
test suites in the hierarchy are descendants of the NeedIt App Test
Suite.
In a test suite hierarchy, tests can be children but cannot be parents.
Test suites can be both a parent and a child. The test suite Email
address syntax validate is:
A child suite of the NeedIt App Test Suite

The parent suite of Another Test Suite
DEVELOPER TIP: If a test is included more than once in a test suite
hierarchy, the test executes only once.
Creating Test Suites

To create a Test Suite, use the Application Navigator to open
Automated Test Framework (ATF) > Suites. Click the New button.
Provide a Name and a Description for the Test Suite.

Click the Save button.
Adding Tests
In the Test Suite Tests related list, use the New button to create a new
test for the test suite. To add an existing test to the suite, double-click
Insert a new row... and enter the name of a test. Select the test from
the list, then click the Save (Enter) button.

The Execution order field determines the order in which the tests
execute. ATF automatically determines the execution order based on
the order in which the tests are added. Developers can modify the
value in the Execution order field to re-order the test execution.
The Abort on failure field indicates whether to stop test suite execution
if a test fails. The default value is false. False means to continue
testing the rest of the suite even if the test fails.

Adding Test Suites

In the Child Test Suites related list, use the New button to create a
new suite for the test suite. Configure the new test suite. Notice the
Parent suite field is automatically set.

To add an existing test suite as a child, open the child test suite for
editing. Manually set the value in the Parent suite field then save the
record.

The Child Test Suites related list displays all suites with the current
suite as its parent.

Running Test Suites

To run a test suite, click the Run Test Suite button.
If the test suite contains test steps that run client-side scripts, you will
be prompted to select a client test runner. After starting a new test
runner, or selecting an existing test runner, click the Run Test Suite
button.

When the test suite execution is complete, view the results in the Run
Test Suite dialog window. The test results shown in the Run Test Suite
dialog follow the test suite hierarchy.
Click the Go to Result button to view the test suite results records.
Results are grouped by Test Result and by Child Test Suite Results.

On the Child Test Suite Results related list, click the Display
hierarchical lists icon (

) to display the suite's tests.

Click the Preview icon ( ) for a test to see the test step results.

DEVELOPER TIP: If tests are running slowly in the client test runner, check
out the How to avoid ATF testing failures
(https://community.servicenow.com/community?
id=community_blog&sys_id=84dc2665dbd0dbc01dcaf3231f96190f) blog on the
ServiceNow community.
Rerunning Test Suites

After fixing an issue discovered by ATF, developers can re-run a test
suite's failed tests without having to execute the entire suite again.
Click the Re-run Failed Tests button to execute only the failed tests
from a test suite.

ATF creates a new suite result hierarchy for the re-run tests. The
progress workers, test result, and test suite result records show the
same suite hierarchy as the previous test suite. They do not include
the tests or suites that passed in a previous run.

If a child suite or test that failed is deleted or deactivated, when the

suite is re-run, ATF does not execute that suite or test in the re-run.
If a child suite or test is added to a suite with a failed test, when the
suite is re-run, ATF does not execute the added suite or test in the re-
run.
Exercise: Create and Run a Test

Suite
In this exercise, you will create and run a parent test suite called the
NeedIt App. The parent test suite will contain a child test suite.
Create a Parent Test Suite - NeedIt App

1. The test suites you create are part of the NeedIt application.
Using the same strategy as in the last exercise, make sure NeedIt
is the current scope.
Navigator to open Automated Test Framework (ATF) > Suites.
4. Configure the new suite.
Name: NeedIt App
Description: Test Suite for the NeedIt application
Create a Child Test Suite - When needed Field

NeedIt App

3. Configure the new suite.
Name: When needed Field NeedIt App
Parent suite: NeedIt App
Description: Testing on the NeedIt When needed field date
Business Rule to make sure it works in three cases: past
date, today, and future.
5. Add the When needed - Past test you created in an earlier
exercise to the suite.
1. Scroll to the Test Suites Tests related list.
2. Double-click Insert a new row....
3. In the search field, type When then select the When needed
- Past test from the list.
4. Click the Save (Enter) button ( ).

6. Add two more tests to the suite:
When needed - Today
When needed - Future
8. Verify the When needed Field NeedIt App suite is a child suite of
the NeedIt App suite.
Suites.
2. Open the NeedIt App test suite record.
3. Open the Child Test Suites related list.
4. Verify the When needed Field NeedIt App suite is on the
related list.
QUESTION: Which one of the diagrams shows the correct hierarchy

for the NeedIt App test suite?
ANSWER: The correct answer is C. The When needed Field NeedIt

App suite contains three tests and is a child suite of NeedIt App.
Running the NeedIt App Test Suite
1. In the NeedIt App test suite record, click the Run Test Suite
button.
2. Examine the Run Test Suite dialog. The NeedIt App suite should
succeed.
3. In the Run Test Suite dialog, click the Expand button ( ) for the
When needed Field NeedIt App suite to see the test results. You
may have to scroll to see all the tests.
5. Explore the Test Results, Child Test Suite Results, and All Test
Suite Results to see what information they contain.
Exercise: Add a Test to the

NeedIt App Test Suite
In this exercise, you will create a test to add to the NeedIt App test
suite. The test will determine if the Requested for email field on the
NeedIt form is the correct email address for the user in the Requested
for field.
Preparation - Explore Client Script Behavior
1. If not still open from an earlier exercise, open the NeedIt

application in Studio for editing.

2. Click the link to the NeedIt application to open it in Studio.
2. Examine the NeedIt Set Requested for Client Script.
1. In Studio, use the Application Explorer to open Client

Development > Client Scripts > NeedIt Set Requested for.
2. Examine the NeedIt Set Requested for logic to get an idea of
what the Client Script does. If you are not that familiar with
scripting in ServiceNow, use the Description field and the
script comments to determine what the script does.
3. Examine the NeedIt Populate Email Field Client Script.
1. In Studio, use the Application Explorer to open Client

Development > Client Scripts > NeedIt Populate Email
Field.
2. Examine the NeedIt Populate Email Field logic to get an idea
of what the Client Script does. If you are not that familiar with
scripting in ServiceNow, use the Description field and the
script comments to determine what the script does.
4. Create a NeedIt record.
1. Return to the main ServiceNow browser window and use the

Application Navigator to open NeedIt > Create New.
2. On the form, notice the value in the Requested for field. This
value is set to the currently logged in user by a Client Script.
3. Notice the value in the Requested for email field. This value
is set to the Requested for's email address by a Client Script.
4. Change the value in the Requested for field to Fred Luddy.
5. Notice the new value in the Requested for email. You do not
need to save the new NeedIt record.
5. Verify Fred Luddy's email address was set correctly.
1. Use the Application Navigator to open User Administration

> Users.
2. Open Fred Luddy's user record.
3. Verify the email address you saw in the NeedIt record
matches the email address in Fred's user record.
Create a Test

Name: NeedIt Set Requested for and Email
Description: Test two NeedIt App Client Scripts: NeedIt
Set Requested for and NeedIt Populate Email Field
Add Test Steps

In this section of the exercise, you will add the test steps to the test.
The Create a User test step does not include an email address in the
created record, so you will use the Impersonate test step for this test.
1. Add an Impersonate test step.
2. In the Add Test Step dialog, select the Server category and
then select the Impersonate test step.
4. Configure the Impersonate test step.
User: Fred Luddy
2. Add a Navigate to Module test step to open a new NeedIt form.
2. In the Add Test Step dialog, select the Application
Navigator category and then select the Navigate to Module
test step.
4. Configure the Navigate to Module test step.
1. Click the Lookup using list button ( ) in the Module

field.
2. Search for Modules where the Application menu
contains *needit.
3. Click the Create New Title from the list.
QUESTION: Why use the test step Navigate to Module instead of

Open a New Form for this test?

ANSWER: The Navigate to Module test step verifies the test user
can access the selected module. In this exercise, the test step is
used to open the Create New module for the NeedIt application,
which opens the same form as the Open a New Form test step,
but with the additional module verification.

3. Add a Field Values Validation test step.
1. In the Test Steps related list click the Add Test Step button.
2. In the Add Test Step dialog, select the Form category and
then select the Field Values Validation test step.
4. Configure a Condition for the Field Values Validation test
step. Hint: Use the Data Pill Picker button ( ) to use the
Impersonate test step output variable as input for the
Conditions.
[Requested for] [is] [(Step 1: Impersonate ➔ User)]
5. Click the AND button, then Configure a second Condition for
the Field Values Validation test step.
[Requested for email] [is] [(Step 1: Impersonate ➔
User ➔ Email)]
Run the NeedIt Set Requested for and Email Test

Using the skills you learned in previous exercises, run the NeedIt Set
Requested for and Email test. All three test steps should complete
successfully.
Add the NeedIt Set Requested for and Email Test

to the NeedIt App Test Suite
2. Open the NeedIt App test suite for editing.
3. Add the NeedIt Set Requested for and Email test to the NeedIt
App suite.
1. In the Test Suite Tests related list, double-click on Insert a
new row....
2. In the search field, type NeedIt then select the NeedIt Set
Requested for and Email test from the list.
3. Click the Save (Enter) button ( ).
QUESTION: Which of the diagrams shows the correct hierarchy for

the NeedIt App test suite?

ANSWER: The correct answer is B. The NeedIt Requested for and

Email test is directly connected to the NeedIt App suite. The When
needed Field NeedIt App child suite is also directly connected to the
NeedIt App suite.
Running the NeedIt App Test Suite
1. In the NeedIt App test suite record, click the Run Test Suite
button.
2. In the Pick a Browser dialog, start a new client test runner or

select an existing runner if one exists.
3. Click the Run Test Suite button.
4. Watch the suite's tests run in the Client Test Runner. The tests
may happen quickly but try to notice:
1. Which test is running

2. What is being tested
3. Error messages caused by submitting the form
5. When the testing is done, return to the window you used to run
the test suite.
6. Examine the Run Test Suite dialog. The NeedIt Requested for
and Email test should have succeeded.

8. Explore the Test Results, Child Test Suite Results, and All Test
Suite Results to see what information they contain.
Parameterized Tests
Parameterized tests run multiple times with different test data for each
run.
Parameterized testing:
Eliminates the need to duplicate test steps to change test data.

Increases test reuse by separating test actions from test data.
Produces a separate test result for each data set.
When a parameterized test runs, Automated Test Framework replaces

the parameters with data set values. For example, a developer can
create a test that creates and verifies an Incident record. Using
parameters, the test runs multiple times with each row from a data set
and verifies the results match expectations. If the Category is
Hardware, the test verifies the Assignment group is set to Hardware

Support. If the Category is Inquiry / Help, the test verifies the
Assignment group is set to Triage.
Creating Parameterized Tests

To create a parameterized test, select the Enable parameterized
testing option on the test form. When the Enable parameterized testing
option is selected, the Parameter Definitions, Test Run Data Sets, and
Parameterized Test Results related lists are visible.
Click the Additional actions menu ( ) and select the Save menu
item before configuring parameterization.
Creating Parameters
Parameters are variables developers can use in test steps to pass
values from a data set to the test step. Parameters can be shared or
exclusive.
Shared Parameters: Parameters that can be used in any

parameterized test. Shared parameters can only be created in the
Global application scope.
https://developer.servicenow.com/print_page.do?release=rome&category=courses&identifier=app_store_learnv2_atf_rome_automated_test… 100/141
Exclusive Parameters: Parameters that are only available to the

current test.
Creating a Shared Parameter
Create shared parameters for variables used in multiple tests. For

example, multiple tests may need to be tested as different users.
Create shared parameters to create variables once then use the
variables in any parameterized test.
In the Parameter Definitions related list, click the Add Shared

Parameters button. If the Add Shared Parameters button is not
available, Global is not the current application scope. An annotation
informs the user that shared parameters can only be created in the
Global application scope.
Click the Switch to Global if you would like to add new Shared
Parameters link in the annotation or use the application picker to
switch to the Global application scope.
Configure the shared parameter. Configuration options vary based on

the type of parameter created.
Type: The data type for the parameter.

Column label: The label seen when creating data sets or
selecting the variable in a test step.
Column name: The name used in scripts and by ATF to access
the variable. This value is automatically configured based on the
Column label, but can be changed before submitting the
parameter. The column name needs to be unique for all
parameters.
Creating an Exclusive Parameter
Set the application scope to the scoped application. In the Parameter

Definitions related list, click the Add Exclusive Parameters button.
Configure the exclusive parameter. Configuration options vary based
on the type of parameter created.
Creating the Data Set

A data set is the runtime data used when the test runs. Each record in
the data set is called a parameter value set. The test runs for each
parameter value set. Use the Test Run Data Sets related list to
configure the data used in the parameterized test.
Use the New button to create a data set record or the Import button to
create multiple data set records at once.
Creating a Data Set Record
In the Test Run Data Sets related list, click the New button. In the New
Parameter Value Set dialog, configure the values for all the
parameters used in the test. All shared and exclusive parameters can
be configured in the parameter value set.
Repeat the process for each parameter value set in the data set.
Importing a Data Set
In the Test Run Data Sets related list, click the Import button. In the
Import Test Run Data Sets dialog, configure the settings for the import.
Configure the import behavior. Imported values can add parameter

value sets to an existing data set or replace any existing parameter
value sets with new data.
Click the Download Excel template button to download a

spreadsheet to populate value sets for import.
Click the Choose File
button to select the populated spreadsheet to import. Click the Upload
button to import the data set.
Applying the Data

Test step fields that accept parameters as their input have a Data Pill
Picker button.

The Data Pill Picker button opens a list of steps with parameters
available for use with input variables. Output variables from previous
test steps may also be available in the list. Click Parameters to open a
list of parameters available to the test.

Click an output variable in the right-hand column to insert it into the

input variable.

Exercise: Create Parameterized

Tests
The NeedIt application has two roles: x_58872_needit.needit_user and
x_58872_needit.admin. A user with either role should be able to create
NeedIt records.
In this exercise, you will create a parameterized test to verify that a

user with each role can open the NeedIt > Create New module and
that fields are visible for a user with the role to create a NeedIt record.
Create a Test with Parameterized Testing

Enabled
Enable parameterized testing in the test to create parameters and a
data set.
1. Verify that the current application scope is NeedIt.

4. Update the test configuration.
Name: Create NeedIt Module
Enable parameterized testing: Selected (checked)
Description: Parameterized test to verify users with
different NeedIt roles can access the module and form to
create a NeedIt record.
Create Parameters
The Create a User step needs a First name, Last name, and Roles to
apply to the new user. In this section of the exercise, you will create a
parameter for each of these fields.
QUESTION: Is the Add Shared Parameters button available on the

Parameter Definitions related list? Why or why not?
ANSWER: The Add Shared Parameters button is not available

because the selected application scope is NeedIt. The Add Shared
Parameters button is only available in the Global application scope.
1. In the Parameter Definitions related list, click the Add Exclusive

Parameters button.
2. Configure the First name parameter.
Type: String
Label: First name
Column name: (This value is automatically populated)
Max length: 40
4. Click the Add Exclusive Parameters button.
5. Configure the Last name parameter.
Type: String
Label: Last name
Max length: 40
7. Click the Add Exclusive Parameters button.
8. Configure the Role parameter.
Type: Reference
Label: Role

Reference: Role
Create a Data Set

In this section of the exercise, you will create a data set for the
parameters to use when testing. You will create one record to test
each of the NeedIt application roles.
1. In the Test Run Data Sets related list, click the New button.
2. Configure the new parameter value set.
First name: NeedIt
Last name: User
Role: x_58872_needit.needit_user
4. Create a second parameter value set.
First name: NeedIt
Last name: Admin

Role: x_58872_needit.admin
Create the Test Steps

The final step to use parameterized testing is to configure the test
steps to use the parameters. In this section of the exercise, you will
add the Create a User, Navigate to Module, and Field State Validation
test steps to the test. The Create a User test step will use the
parameter values.
1. Switch to the Test Steps related list.
3. In the Add Test Step dialog, select the Server category and then
select the Create a User test step.
https://developer.servicenow.com/print_page.do?release=rome&category=courses&identifier=app_store_learnv2_atf_rome_automated_test_… 110/141
5. Configure the Create a User test step.
First name: (Parameters ➔ First name)

Last name: (Parameters ➔ Last name)
Roles: (Parameters ➔ Role)
7. Add a Navigate to Module test step to open a new NeedIt form.
1. Click the Add Test Step button.
2. In the Add Test Step dialog, select the Application

Navigator category and then select the Navigate to Module
test step.
4. Configure the Navigate to Module test step.
1. Click the Lookup using list button ( ) in the Module

field.
2. Search for Modules where the Application menu
contains *needit.
3. Click the Create New Title on the list.
8. Add a Field State Validation test step to verify fields on the new
NeedIt form.
1. Click the Add Test Step button.
2. In the Add Test Step dialog, select the Form category and
then select the Field State Validation test step.
4. Configure the Field State Validation test step.
1. Check for visible fields.
1. Click the Unlock Visible button.
2. In the Available slushbucket, select Number.

3. Click the Add Item button to move Number to the
Selected slushbucket.
4. Repeat this process to check the visibility of other
fields.
Priority
State
Short description
Description
2. Check for mandatory fields.
1. Click the Unlock Mandatory button.
2. Add fields to the Selected slushbucket to check for

the mandatory flag.
Requested for
Requested for email
Request type
What needed
When needed
Test
Verify the test completes successfully for both users.

2. In the Pick a Browser dialog, start a new test runner or use an
existing one if open.
4. Watch the Client Test Runner as the test steps execute. When the
test steps finish and the Client Test Runner says Waiting for a test
to run, return to the browser tab where the Create NeedIt Module
test is open.
5. Examine the Run Test dialog. The tests should have succeeded.
7. Examine the Test Results related list. Note that each record in the
list is the test run with a different value set.
Challenge
Add the parameterized test to the NeedIt App test suite. Test the test
suite to verify all tests complete successfully.
CHALLENGE SOLUTION:

To add the test to the NeedIt App test suite, open the NeedIt App test
suite. Add the Create NeedIt Module test to the Test Suite Tests
related list.
If you build more tests to verify access, you may want to group access
tests together in a suite.
Scheduling
ATF developers can schedule test suites to run at a specific date and
time. Designated users are notified when scheduled test suites finish
execution.
The generalized procedure for scheduling test suite execution is:
1. Create a schedule.
1. Set frequency.
2. Set time.
2. Assign tests suites to the schedule.
1. Add users to the watch list.
2. If the test suite contains client-side tests:
1. Select a client test runner browser and browser version.
2. Select a client test runner OS and OS version.
3. If the scheduled test suites include client test steps, create
scheduled client test runners.

Create a Schedule
To create a schedule, open Automated Test Framework (ATF) >
Schedules and click the New button.

Name: A descriptive name for the schedule.

Active: Select to add the schedule to the ServiceNow scheduler.
When not selected, the schedule will not run.
Run: Select the frequency to run the schedule: Daily, Weekly,
Monthly, Periodically, Once, On Demand, Business Calendar:
Entry Start, or Business Calendar: Entry End.
Time, Day, Starting, Repeat interval, Days, Hours: These fields
are available on the form only for certain Run values and are used
to specify when to run the schedule.
Conditional: Select to display the Condition script field.
Condition: A server-side script to determine if the test suites
schedule should run as scheduled.
Condition Script
Condition scripts are optional in ATF schedules. Condition scripts are
evaluated when the scheduled time is met. The last line of a
condition script must evaluate to either true or false (Not return
true or false...evaluate to true or false). If the condition script evaluates
to false, the test suites in the schedule will not run. In the example
script, the ATF schedule is a Daily schedule set to run at 7:00 PM. The
condition script prevents the test suites from running on weekend days
even though the schedule is a Daily schedule.
DEVELOPER TIP: Condition scripts are not evaluated when testing schedules
using the Execute Now button.
Add Test Suites

To add test suites to a schedule, scroll to the Schedule Suites related
list and click the New button. Configure the Scheduled Suite Run
record.

Execution order: Order of suite execution on the schedule. If this

field is empty, ServiceNow executes the suites in the order they
are added to the schedule.
Test suite: The ATF test suite to add to the schedule.
Watch list: List of users to receive an email notification when the
schedule completes.
Browser name: If the test suite has UI (client-side) test steps,
select a browser for the steps to run on. The browser must have a
running scheduled client test runner to use when running the
suite. If set to Any, ATF uses any available scheduled client test
runner. If no scheduled client test runner is available with this
browser version, ATF does not run the suite.
Browser version starts with: If the test suite has UI (client-side)
tests steps, the scheduled client test runner must run under this
OS. If set to Any, ATF uses any available scheduled client test
runner. If no scheduled client test runner is available with this OS,
ATF does not run the suite.
OS name: If the test suite has UI components, the scheduled
client test runner must run under this OS. If no scheduled client
test runner is available with this OS, ATF does not run the suite.
OS version starts with: If the test suite has UI components, the
OS version for the scheduled client test runner must start with this
string. If no scheduled client test runner is available with this OS
version, ATF does not run the suite.
DEVELOPER TIP: A test suite can appear more than once in a schedule to
allow a single schedule to test the same suite on multiple browsers/browser
versions/OSs/OS versions.
Scheduled Client Test Runners

ATF uses scheduled client test runners to execute schedules
containing test suites with client-side test steps. Scheduled client test
runners only run scheduled test suites.
To create a scheduled client test runner, open Automated Test

Framework (ATF) > Run > Scheduled Client Test Runner. Repeat
this step on every browser/browser version/OS/OS version on which
the schedule's test suites will run.
ATF administrators can view the running scheduled test runners using
the Automated Test Framework (ATF) > Run > Active Scheduled
Test Runners module.
If the browser/browser version/OS/OS version specified for a

scheduled test suite is not available, ATF skips the test suite.

Scheduled Test Notifications
When scheduled test suites run, users and email addresses on the
Scheduled Suite Run record's Watch list receive the Test Suite Results
report by email.
Test Suite Results

The Test Suite Results email is a clickable report showing run results
at the schedule, suite, and test levels.

ATF administrators can change the email properties using the

Automated Test Framework (ATF) > Administration > Properties
module. The configurable options are:
Whether to display results from passing tests (default is to show

only failed test results)
Maximum number of test results to display (default is 10)
Maximum depth when printing suite results (default is 20)
Colors to indicate results: failed, errored, passed, skipped, and
canceled.
Watch List
To edit the watch list, click the Unlock Watch list ( ) button.

Exercise: Create and Run a

Schedule
In this exercise, you will create and run a suite schedule that executes
on the first of every month.
Preparation
Include a test that fails in the suite to see how failed tests appear in
the results.

2. Open the NeedIt Set Requested for and Email test for editing.
3. Click the Copy Test button.
4. Rename the test NeedIt Fail Test.
5. Save the record by clicking the Additional Actions menu ( )

and selecting the Save menu item.
6. Update the Field Values Validation test step to ensure it fails. For
example, change the condition [Requested for email] [is] [(Step 1:
Impersonate ➔ User ➔ Email)] to [Requested for email] [is not]
[(Step 1: Impersonate ➔ User ➔ Email)].
8. Add the NeedIt Fail Test test to the NeedIt App test suite.
Create a Suite Schedule

Schedules.
3. Configure the Suite Schedule:
Name: NeedIt App Suites
Active: Selected (checked)
Run: Monthly
Day: 1
Time: [Hours] [02] [00] [00]
Add a Scheduled Suite

1. Scroll to the Scheduled Suites related list and click the New
button.
2. Configure the new Scheduled Suite Run record.
Test suite: NeedIt App
Browser name: Any
OS name: Any
3. Add your email address to the Watch list.
1. Click the Unlock Watch list button ( ).

2. Type your personal or work email address into the Enter
email address field.
3. Click the Add email address button ( ).

Execute the NeedIt App Suites Schedule

1. Click the Execute Now button to execute the Schedule Suite.
2. Examine the Run Scheduled Suites results dialog to determine
why the schedule did not run.
QUESTION: Why did the schedule not run?

ANSWER: Schedules with client-side (UI) test steps require a

scheduled client test runner in order to execute. There are currently no
active client test runners.

Launch a Scheduled Client Test Runner and Run

Again
1. In the Application Navigator, right-click Automated Test
Framework (ATF) > Run > Scheduled Client Test Runner and
select the Open Link in New Tab menu item (or whichever menu
item opens a link in a new tab in your browser).
2. In the NeedIt App Suites schedule, click the Execute Now button.
3. Switch to the browser tab where the scheduled client test runner
is executing. You should see the test steps from the NeedIt Apps
Suites schedule executing.
4. When the schedule execution completes, examine the Run
Schedule Suites dialog to see the results.
Examine the Test Suites Results Email
IMPORTANT: Email services are temporarily disabled on Personal Developer
Instances (PDIs). View sent email messages in System Logs > Emails
instead of in your email application. Open an email record and click the
Preview Email Related Link.
1. In your email application, open the Test Suite Results for NeedIt
App email that was sent by the schedule. You may have to wait a
minute or two for the email to arrive. If the email does not arrive,
check your spam folder.
2. Explore the email to see what it contains. Click any of the links
you would like to investigate.
QUESTION: Why is the NeedIt Fail Test the only result included in the
email?
ANSWER: By default, only failed test results appear in the email. To

see all test results in the email, open Automated Test Framework
(ATF) > Administration > Properties and deselect (uncheck) the
Boolean value for results displayed in scheduled suite email results
property.
Run the Schedule in a Different Browser
1. If not still open, open the NeedIt App Suites schedule for editing.
2. In the Schedule Suites related list, click the Preview button ( )

for the NeedIt App test suite.
3. Click the Open Record button.
4. Configure the Client Constraints to use a different browser and/or

OS than you have been using to test. Set the values according to
the browser(s) and/or OSs you have available to you. For
example, if you have been working in Chrome, set the browser to
Firefox. After modifying the browser, click the Update button.
5. Go to the browser on the OS you configured in the Client

Constraints.
6. In the new browser, log in to your personal developer instance as

the admin user.
7. In the Application Navigator, open Automated Test Framework

(ATF) > Run > Scheduled Client Test Runner to open a
scheduled client test runner.
8. Return to the browser where you have been doing your

development work and run the NeedIt App Suites schedule.
9. Go to the second browser and watch the schedule execute in the

scheduled client test runner.
10. When the schedule finishes, examine the email to make sure the
schedule results are what you expected.
11. Return to the browser where you have been doing your
development work and use the Application Navigator to open
Automated Test Framework (ATF) > Run > Active Scheduled
Test Runners.
12. Open the record for the scheduled client test runner on the
second browser.
13. Click the Delete button to terminate the scheduled client test
runner on the second browser.
14. When prompted to confirm the record deletion, click the Delete
button.
15. Return to the second browser and notice the scheduled client test
runner has the status of Disconnected. Close the browser tab.
16. If you have any other scheduled client test runners running,
delete them as well.
Remove Your Email Address from the Schedule -

Optional
If you would prefer not to receive monthly emails from the NeedIt App
Suites schedule, remove your email address from the watch list.
1. If not still open, open the NeedIt App Suites schedule for editing.
2. In the Schedule Suites related list, click the Preview button ( )

for the NeedIt App test suite.
3. Click the Open Record button.
4. Click the Unlock button ( ) for the Watch list.

5. Click your email address to select it, then click the Remove
selected item button ( ).

Exercise: Save Your Using the

Work (Optional)
Source control applications, like GitHub, allow developers to commit
changes (save completed work) outside of the Personal Developer
Instance (PDI). Commit changes made to the application to save your
work in source control.
In this exercise, you will save the work completed in this module to
your GitHub repository.
NOTE: See the GitHub Guide (/dev.do#!/guide/rome/now-platform/github-
guide/github-and-the-developer-site-training-guide-introduction) for more information
on how ServiceNow uses GitHub with the Developer Program learning content
and to see a video on how to save your work.
Commit Changes
1. If the NeedIt application is not open in Studio, open it now.

2. In the Select Application dialog, click the application.
2. Open the Source Control menu and select the Commit

Changes menu item.
3. Select the updates to commit.
1. In the Select files to commit to source control for

<Application> dialog, select All Update Sets.
2. Review the application files to be committed.
3. Click the Continue button.
4. In the Confirm files to commit to source control for NeedIt dialog,

enter a Commit comment, such as Using the Automated Test
Framework Module Completed.
5. Click the Commit Files button.
6. When the Commit Changes dialog reports success, click the

Close button.
NOTE: If the commit change fails, you may have entered the
ServiceNow repository URL in the URL field instead of the forked
repository URL. See the Troubleshooting GitHub Issues
(/dev.do#!/guide/rome/now-platform/github-guide/troubleshooting-github-issues)
section in the GitHub Guide for instructions on how to troubleshoot
GitHub connection issues.
Test Your Automated Test

Framework Knowledge
Want to verify your understanding of Automated Test Framework
(ATF)? These questions will help you assess your progress. For each
question, determine your response then click anywhere in the question
to see the answer.
QUESTION: Why is running ATF tests and suites disabled by default?
1. Tests and suites should only be run in production instances with

real data.
2. Tests and suites should only be run in non-production instances.
3. Tests and suites need to be built before making testing active.
4. Tests need to be answered with number 2 pencils to be graded.
5. Tests and suites need to be tested in non-production instances
before they are moved to production.
ANSWER: The correct response is 2. Even though ATF rolls back

steps run during a test, tests could impact data. Tests and suites
should only be run in non-production instances and never in
production. Instead, production instances should be cloned to a non-
production instance for testing.

QUESTION: How do you run a test as a different user? More than one
response may be correct.
1. Use the Create a User test step.

2. Use the Create and Impersonate User test step.
3. Impersonate the user before running the test.
4. Log in as the user before running the test.

5. Use the Impersonate test step.
ANSWER: The correct responses are 1 and 5. The Create a User and
Impersonate test steps allow you to impersonate a different user for
the test. For the Create a User test step, be sure to configure the step
to Impersonate this user. The Create and Impersonate User test step
does not exist. A user may not have permissions to run ATF tests, so
impersonating a user or logging in as a user before running the test
would not work.
QUESTION: Which of the following describes a way to order test steps

in a test? More than one response may be correct.
1. Set the Order field in the Test Steps related list.

2. Drag and drop the steps into the order to run.
3. Select where to insert the step when adding the step to the test.
4. Set the Execution order field in the Test Steps related list.
5. Steps need to be created in the order they run.
ANSWER: The correct responses are 3 and 4. Select where to insert

the new test step using the Insert after choice list in the Add Test Step
dialog when adding the step to the test. Alternately, change the
Execution order values to reorder steps.
Test steps do not have an Order field. No interface allows test steps to
be reordered by dragging. Test steps can be reordered after creation.
QUESTION: How do you use data from one step in a test in a later
step?
1. Write a script to open the test step object to get the data to use in
the later step.
2. Click the step in the Data Panel and select the data to use in the
later step.
3. Create variables on the test and write scripts to populate the
variables when the test executes.
4. Click the Reference button and select the record from the table.
5. Click the Data Pill Picker button and select the variable from the
data pill picker.
ANSWER: The correct response is 5. Previous steps with output

variables can be selected. Data is represented as a data pill in the
interface. No scripting is required to access data from previous steps.
QUESTION: What is the purpose of a Test Template?
1. A test template is a reusable set of test steps that are commonly

used together to make test creation easier.
2. A test template is a set of reusable questions to make training
knowledge checks easier to create.
3. A test template is a reusable test that can be run with different
values to test with different data.
4. A test template is hierarchical grouping of related tests to run
multiple tests together as a single job.
5. A test template is an ordered sequence of steps to test that
automates testing in ServiceNow.
ANSWER: The correct response is 1. Test templates make the

creation of similar tests quicker and easier.
Parameterized tests run a single test with different data. A suite is a

grouping of related test to run multiple tests together as a single run. A
test is an ordered sequence of steps that automates testing.
QUESTION: True or False? Developers can assert the expected result

from a test step so that when a record fails to insert, the test step is
successful.
ANSWER: The correct response is true. Developers can configure

test steps with assertions based on the intended result.
QUESTION: Which of the following is the purpose of a test runner?
1. Execute client-side test steps

2. Execute server-side test steps
3. Execute tests on a schedule
4. Execute tests in a specific browser
5. Execute with different data
ANSWER: The correct response is 1. The full name for a test runner is
client test runner. Test runners execute the client-side test steps
included in a test. While test runners can be launched in specific
browsers, the main purpose is to run the client-side test steps.
QUESTION: How can a developer re-run only failed tests when a test
suite runs? More than one response may be correct.
1. Fix the issue and click the Re-run Failed Tests button in the Test
Suite Result record.
2. Fix the issue and run the test suite again.
3. Fix the issue, open the failed tests from the Test Suite Result
record, and click the Re-run Test button.
4. Fix the issue and click the Re-run Failed Tests button in the Run
Test Suite dialog.
5. Schedule the suite to run at a better time when all tests will
succeed.
ANSWER: The correct responses are 1 and 4. Regardless of how the

failed tests are run, the failure should be fixed before re-running the
tests.
Fixing the issue and running the test suite again runs all the tests, not
just the failed tests. Tests cannot be re-run from the individual test
results under the Test Suite Result.
QUESTION: How can a developer create test run data sets for
parameterized tests? More than one response may be correct.
1. Link to a table and run the test for every record in a table.
2. Manually create parameter value sets.
3. Import a spreadsheet with the data.
4. Write a REST web service call to a data source.
5. Write a JavaScript to generate random data.
ANSWER: The correct responses are 2 and 3. Parameter value sets

can be created manually or imported from a spreadsheet. The import
process will create a template spreadsheet to populate.
QUESTION: Which of the following are true about scheduling in ATF?

More than one response may be correct.
1. Scheduling allows tests to be scheduled to run at a specific date

and time.
2. Schedules can be configured to test specific browsers and
browser versions.
3. Schedules can be configured to test specific operating systems
and operating system versions.
4. Schedules run at a configured frequency.
5. Schedules send results to a watch list of users after completion.
ANSWER: The correct response is 4. This is a trick question.

Scheduling allows test suites to be configured to run at a specific date
and time, not tests. Developers configure browser, operating system,
and watch list details on the test suites assigned to the schedule, not
the schedule itself.

Framework Module Recap
Core concepts:
The Automated Test Framework (ATF) is a ServiceNow

application for performing tests on an instance
Test driven development
Regression testing
Routine instance testing
By default ATF disables running tests and test suites; an ATF
administrator must enable the ability to run tests and test suites
NEVER run ATF on a production instance
Tests are made up of configured test steps
Many tests start with an Impersonate test step to make sure the
correct roles are applied during testing
A client tests runner is required for any client-side test step
Developers can manually execute tests
Output variables from one test step can be used as input
variables to another test step
Test templates are a reusable set of test steps which can be used
to quickly create tests
Test suites are a hierarchical, logical grouping of tests and other
test suites
Developers can manually execute test suites
Scheduled test suites automatically run at a specified frequency
Scheduled test suites send reports by email to users on the watch
list
Scheduled test suites with client-side test steps:
Require scheduled client test runners
Can be assigned a browser and/or OS for testing
Scheduled test suite email reports contain clickable links to the
test suite, tests, and test results
ATF administrators can configure scheduled test suite email
report properties such as whether or not to report on successful
tests
After Completing Using the

Automated Test Framework, You
Might Also Be Interested In...
Congratulations on completing the Using the Automated Test
Framework module. Based on your interest in automated testing, you
might also enjoy:
Service Portal Introduction (http://developer.servicenow.com/to.do?

u=ATF-R-MOD-SPI): In this Developer Site learning module, you
will create and test a Service Portal using baseline widgets.
Building a Test Case Generator for ATF
(http://developer.servicenow.com/to.do?u=ATF-R-LCH-
TestCaseGenerator): In this Live Coding Happy Hour video, you will
learn how to build an Automated Test Framework test case
generator.
Automated Test Framework Documentation
(http://developer.servicenow.com/to.do?u=ATF-R-DOC-ATFLanding): On
the ServiceNow docs site, you will find the complete set of
reference material for the Automated Test Framework.

Course - Automated Test Framework - ServiceNow Developers

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Course - Automated Test Framework - ServiceNow Developers

Uploaded by

Copyright:

Available Formats

10/28/22, 7:33 AM Course | Automated Test Framework - ServiceNow Developers

Automated Test Framework

The Automated Test Framework (ATF) is a ServiceNow application to test

Using the Automated Test Framework

ARTICLES IN THIS MODULE:

Automated Test Framework Objectives

About This Learning Module

What is the Automated Test Framework?

Enabling and Running Tests

Viewing Test and Test Step Results

Exercise: Run Example Tests

Creating Tests and Adding Test Steps

Exercise: Create a Test

Using ATF Variables

Exercise: Use an Output Variable

Creating Test Templates

Exercise: Fork Repository and Import Application for the

Exercise: Create a Branch for Using the Automated Test

Exercise: Create a Test Template

Exercise: Create Tests from a Template

Asserting Test Success

Exercise: Assert Test Success

Creating Test Suites

Running Test Suites

Rerunning Test Suites

Exercise: Create and Run a Test Suite

Exercise: Add a Test to the NeedIt App Test Suite

Creating Parameterized Tests

Exercise: Create Parameterized Tests

Scheduled Client Test Runners

Scheduled Test Notifications

Exercise: Create and Run a Schedule

Exercise: Save Your Using the Automated Test Framework

Test Your Automated Test Framework Knowledge

Using the Automated Test Framework Module Recap

After Completing Using the Automated Test Framework, You

Using the Automated Test

Automated Test Framework

Create and run tests

Use output variables from a test step as input variables in another

About This Learning Module

Rome ServiceNow release.

Various examples are used on the concept pages in this learning

Exercise icon in the Navigation pane.

The NeedIt application allows users to request services from multiple

What is the Automated Test

Test driven development: Testing while developing new

Use ATF to test:

Service Catalog in Service Portal

For example, before an upgrade, Beth Anglin is able to create records

ATF provides examples of tests for a variety of different actions. To

The Open an Existing Record Test

1. Impersonate the ATF user

3. Validate values on the form

ATF takes screenshots of client-side steps. Developers can view the

If a user were to manually perform these steps, they would do these

Step 1 - Impersonate the ATF User

Step 2 - Open the ATF User Form

Step 3 - Verify Values in the User Record Fields

Although it is possible for a user to manually perform the test, ATF

Enabling and Running Tests

instances. Running ATF in production is neither recommended nor supported.