Automated Test Framework (ATF): Testing Errors, Info Messages, and Field Messages

It's nearing the holidays so I may wind down a bit on the posts, but did want to document this post I left earlier on the ServiceNow Community here. If you haven't used ATF yet or are on the fence about it, I recommend starting to work it in to your development process if possible. A great goal is to have end-to-end testing for processes especially during upgrade time, but learning ATF to create end-to-end testing is a lot for one person to accomplish. ServiceNow has introduced the quick start tests, which may work for organizations that are new or have stayed mostly out-of-the-box, but for customers that have had ServiceNow for a while, most of the time the quick start tests aren't going to cut it. Once I started working for a client that had ATF as part of their development process, I was able to put it into action for the code I worked on, which ultimately lead me to learn it a lot faster than I think I would have if I was working on an epic of stories to automate testing for a process. Ultimately, I would suggest having some sort of tracking or game plan for your development ATFs if you plan to use them in an end-to-end ATF one day, for example using Test Suites, because having a lot of scattered ATFs for development stories can become overwhelming.

There's not a lot of information out there regarding how to test messages that appear to users in ATF so I decided to write an article on what I've found. I'm on the Orlando version of ATF, but have checked in Paris too and this feature just isn't OOTB quite yet, but perhaps in the future. In the mean time, there's an easy enough workaround.

Scenario 1: User clicks a UI Action

In this scenario I've created a server-side UI Action that will display an error message to the user when needed fields on a form are blank. In my real-life scenario I had to ensure these fields had data before I called a Script Include to make an API call, so it was very important I went ahead and stopped the process and informed the user to reduce API traffic on the system. I set up the test as normal:

  1. Inserted/Queried a record to test, left the fields I was keying on blank.

  2. Opened an Existing Record, created in 1.

  3. Clicked the UI Action in question, and asserted that 'Page was reloaded or redirected'

  4. Used the Assert Text on Page (Custom UI) test step to verify the error message I was returning was on the page.

Scenario 2: Business Rule

Same concept as above, but I wanted to show this with a server-side action other than a UI Action. For this scenario I used the same record, and created an onBefore Business Rule to abort and show a message if the user tries to update a Windows server without filling in the OS Domain.

  1. Reused same record from above.

  2. Opened an Existing Record

  3. Set Field Values, attempted to change Serial Number

  4. Submitted form - Form submitted to Server (This is important because our Business Rule needs to hit it)

  5. Used the Assert Text on Page (Custom UI) test step to verify the error message I was returning was on the page.

Scenario 3: Client Script

For this scenario I created a Field Message when the user added input to the Serial Number field on the form.

  1. Used the same Windows Server record as in the previous two examples

  2. Open Existing Record

  3. Set Field Values

  4. Used the Assert Text on Page (Custom UI) test step to verify the error message I was returning was on the page.

While the scenarios are different, the testing step is the same. The Custom UI Test Steps are very powerful when working with UI Pages, etc. but can be used to test out-of-the-box platform features such as messages. So next time you need to test messages displayed to a user, give the Assert Text on Page (Custom UI) test step a try. If you have more scenarios to add to this or have questions please leave them below and I'll update this article as time allows.

Also here's a small ATF Pro Tip:

If you close out your Client Test Runner tab, and need to run the test again, you may see it thinks you have the current CTR still active. No worries, in the Application Navigator search for Client Test Runner and right click to Open Link in New Tab:

255 views0 comments

Recent Posts

See All