Server category

Perform server-side operations. For example, query and update a record, impersonate a user, or run a server-side script.

Create a User

Create a user with specified roles and groups for the test. The user record gets rolled back after the test completes.

Impersonate

Impersonate the specified user for the test.

Impersonate specifies a user for executing subsequent steps in this test. It works for both server-side and browser-side steps and stays in effect until changed with another Impersonate step or until the test ends. The impersonation automatically ends when the test is over.

Note:

• Do not impersonate a user with the test author role. Doing so can lead to conflicts that interfere with executing the test.

• Tests which involve impersonated users which no longer exist fail.

  Tip: It is recommended to create a new user to avoid data dependencies. See Create a User, for more information.

• Do not rely on user IDs being consistent across different instances. The system dynamically assigns users IDs, so the ID for a particular user often differs from one instance to the next.

• When exporting and importing automated tests, keep in mind that update sets do not update the user field.
• Tests can impersonate users with the snc_external role, which allows testing users who do not have login access. See Explicit Roles for requirements of the snc_external role.

Search for a Catalog Item

Searches for a catalog item or record producer in the specified catalog and category. You can perform this step both in Platform and Service Portal.

Record Query

Query the database to verify that a record exists matching the conditions set in this step.

Note: If you don’t update your record query test step, the original record query test step still functions the same way as before, irrespective of it being termed as (Deprecated).

Record Insert

Inserts a record into a table with the field values you specify.

Record Update

Changes field values on a record on the server.

Note: To ensure that the changes were applied, follow this step with a Record Validation step.

Note: Record Update step succeeds even if a field on the record is blocked by ACL. Use the Record Validation step after Record Update to check whether a particular field was modified, or use the Form steps to evaluate ACL conditions for individual fields on a record.

Record Delete

Deletes a specified record in a table.

Record Validation

Validates that a record meets the specified conditions on the server side.

For the Record Validation step, specify the values you want to test using the standard conditions builder. You can apply several conditions to the same field.

This step passes if the overall condition is satisfied and fails if it is not. If you need to test the values of individual fields independently of each other, include a separate Record Validation step for each value to be tested.

Run Server Side Script

Executes a script on the server.

Note: If the script creates data, the system rolls back that data after all steps in the test finish. The output for the Run Server Side Script test step now indicates the line and the line number for the cause of failure.

• Test script

  //  Test step 1 - add data
  var now_GR = new GlideRecord('sc_task');
  //  this sample step's Step config has Output variables named table and record_id
  outputs.table = 'sc_task';
  outputs.record_id = gr.insert();
  //  Test step 2 - access added data and validate
  //  check that the record exists (or that business logic changed it)
  var now_GR = new GlideRecord("sc_task");
  gr.get(steps(PREVIOUS_STEP_SYS_ID).record_id);
  assertEqual({name: "task gr exists", shouldbe: true, value: gr.isValidRecord()});
  stepResult.setOutputMessage: Log a message to step results after step executes.
                               Can only be called once or will overwrite previous message
  

• Create a suite of test scripts

  var now_GR = new GlideRecord('sc_task');
  gr.setValue('short_description', 'verify task can be inserted');
  var grSysId = gr.insert();
  var justCreatedGR = new GlideRecord('sc_task');
  if (justCreatedGR.get(grSysId)) {
  stepResult.setOutputMessage("Successfully inserted task record");
  return true; // pass the step
  } else { 
  stepResult.setOutputMessage("Failed to insert task record");
  return false; // fail the step
  }
  

• Jasmine test

  describe('my suite of script tests', function() {
  it('should meet expectations', function() {
  expect(true).not.toBe(false);
  });
  });
  //  make sure to uncomment jasmine.getEnv().execute(); outside the function body
  assertEqual: A function used to compare that assertion.shouldbe == assertion.value;
  in case of failure it throws an Error and logs that the assertion by name has failed
  

  Note: describe is only supported in Global scope. Use describe to create a suite of test scripts and it to define test expectations.

• Logs message to test step output

  var testAssertion = {
  name: "my test assertion",
  shouldbe: "expected value"
  value: "actual value",
  };
  assertEqual(testAssertion); // throws Error, logs message to test step output
  

• See Step Execution Scripts for Run Server Side script example.

Replay Request Item

Get the item and requester from an existing request item, add the item to a new cart for that user, and place an order.

Related topics

Automated Test Framework use case: test a Service Catalog request

Log

Logs a message and stores it as a step result.

The log message can contain variables and other information pertaining to the test. The message is stored as a step result.

Add Attachments to Existing Record

Add one or more mandatory attachments to the specified record. Use Upload Attachments to select from the attachments the test step adds to the record.

Checkout Shopping Cart

Submits the cart and generates a request. You can perform this step both in the ServiceNow AI Platform and Service Portal.

Custom Scripted StepConfig

Provides an example of scripts for a custom step configuration.

This example checks if the user name provided starts with the letter A. This step is useful primarily to users with the [atf_test_admin] role. Users with the [atf_test_admin] role can view the example scripts by opening the record for this step in Step configurations.