Dave Slusher

4 minute read

If you have followed my work as a developer advocate for ServiceNow at all, you will have noticed that I love automated testing. Even before the original release of the Automated Testing Framework, I presented on testing at Knowledge15. This is really a chunk of the platform close to my heart. This year at Knowledge18, Boris BC, Robert Rabczynski and myself presented on using ATF to perform test driven development on ServiceNow. With the release of London, we get ever closer to the ability to do that in a complete fashion. I am told it will get even better, but let us look at what changed in the London release.

Application Navigator Test Steps

One of the fundamental aspects of setting up a ServiceNow application is verifying that the application and/or modules are or are not showing in the application navigator for a given user with a given role. This is pretty tedious stuff and as we know the heuristic, the more tedious the task the more we want a robot to do it. As of London, there are test steps to assert whether menus and modules are visible.

Negative Assertions for Server Test Steps

You can now choose the Assert Type as either positive or negative when using any of the following test steps:

  • Record Query
  • Record Insert
  • Record Update
  • Record Delete
  • Record Validation
  • Search for a Catalog Item

This allows you to set up an automated test where the correct result is the negative of the step. For example, if you want to verify that a specific record does not exist on the system or no record of a certain criteria, you can do a Record Query with a negative test result. In this case, the test passes when the query turns up no records. Previously that would have been a failure no matter what your intention.

Introduction Service Portal

As of London, Service Portal enters the world of ATF! For Service Portal forms, you can now execute any of the following test steps:

  • Open a Service Portal form
  • Set field values
  • Validate field values
  • Validate field states
  • Check UI Action visibility
  • Click a UI Action
  • Validate form submission

This is not yet to the world of testing all the variety of possibilities of Service Portal widgets with their many possible interaction modes, but it is a beginning of bringing Service Portal into the library of automated tests.

Whitelisted Client Errors

In some cases, you may receive client-side errors in the JavaScript console while running your test. Previously, those would automatically generate test failure. Now you have the ability to whitelist certain errors from the Test Results page.

Client-side errors in ATF

You can choose to handle this error by ignoring completely future occurrences of this error logging the warning. (“Add all client errors to warning list”)

Whitelist as warning

You can also choose to completely ignore these errors completely. (“Add all client errors to ignored list”)

Whitelist as error

This functionality could be useful particularly in cross-browser testing. It is possible that some client-side code has a benign DOM error or the like in one browser but no other. Automated testing breaks down when you are forced to see an error but know that error is going to happen. Ideally any test failure maps to developer action to take. By whitelisting these client errors, you can get closer to that ideal for arbitrary client-side JavaScript code.

New Service Catalog Form Test Steps

There are now additional test steps available to test Service Catalog functionality. You can open and submit record producers, handle all the variable and validation steps, order and validate the items. For individual items you should be able to test an order end-to-end. At this point, you can’t assert a multiple item cart. That is still for the future, but now you should be able to carry individual catalog items through the full cart cycle with every permutation of variables.

Screenshot timeout interval setting

You can now set a timeout for screenshots in the Automated Test Framework Properties. By default this is set to 60 seconds. If after 60 seconds the screenshot cannot be taken, it is skipped. However, if for some reason you need a longer timeout based on the networking or performance characteristics of a test runner or possibly a page with a long lifecycle, you can increase this. Note that this will affect the total time it takes tests to run, but then again they are robots and are not paid by the hour (unless they are on a cloud VM and then maybe they are.)

ATF is always one of my favorite parts to explore of any new ServiceNow release. For those of similar passion as myself, I hope you get a chance to dig around inside the system and see how these new features, steps and assertions can be used to create value for your development organization.