Open Site Navigation

Create a User Test Step in ATF



I've been doing a lot of work with Automated Test Framework lately, as I stand up the ITSM Test Suites in anticipation for an upcoming Rome upgrade. As I work through each of the Quick Start Suites, I have been doing some refactoring especially with Tests that were created before New York or not modified that still utilize the Impersonation Test step. I've linked a helpful product doc below that shows which release a quick start test was implemented in to be aware of the types of test steps they ship with.


I'm highlighting the Create a User test step because I've found it extremely helpful in ensuring I am promoting dynamic tests that can be utilized in any of my instances (except Production ^_^) without me having to ensure I have specific testing users with specific data, roles, etc. associated.


The Impersonation test step is still useful while creating tests but there are some drawbacks to using this step such as:

  1. A hardcoded test user may not be present in an instance, or it may have modified data and/or roles/groups.

  2. Have to ensure hardcoded test users are promoted through the instance stack that is being tested.

  3. Attributes have to be pre-defined in the sys_user record itself, or updated during the Test using Record Update test steps, and test steps to grant membership in Groups to associate roles.

  4. Per ServiceNow, Impersonating an existing user may cause unexpected behavior during testing.


The Create a User test step is such a great replacement to the Impersonate test step due to the following:

  1. You can either grant roles directly or via Group membership, or a combination of both depending on what you're trying to test.

  2. You can create as many users as needed for your test, for example an end-user for the Caller field on an Incident, a fulfiller user for the Assigned to, and an Approver user all within the test.

  3. You can define attributes or not for the user on the Create a User test step such as an email address, phone number, manager, etc. If you don't need user attributes for the test, you don't have to define them. These attributes are especially helpful if you need to dot walk to them when creating/updating/validating records. For example, let's say you have a dot walked Manager field on an Incident form, and you want to verify it has the value of the Create a User test step Manager, you can dot walk within the data pills of the test step, which I'll display below.


In my opinion the Create a User test step saves me so much more time because I can populate the data needed for my test, instead of doing it directly on a sys_user record and maintaining the data on that record. You could perform a Record Query for a user that meets this criteria, but you can't control the attributes of that user if needed unless you add another Record Update test step. I'm not sure which release ServiceNow allowed for the creation of field values in the Create a User test step but I see on the community previously, that you had to use the Create a User test step, and then a Record Update test step in order to control attributes, so I'm glad ServiceNow has made this much easier.


Now let's take a look at the test step itself and some helpful ways the test step can be used. I'm going to run through setting a Caller and Assigned To on an Incident, and then I'll throw an Approval in just for proof of concept.


Creating Users


What I'm going to do first is create my Approver user, which will also serve as the Manager for my Caller user, and then create my Fulfiller user which is a Service Desk member that I'll impersonate. I've also added Caller.Manager to my Incident form to show how you can test dot walked fields.





Utilizing Users in Records


Next, I'll add a Record Insert test step and add my Caller and Assigned To in. Unfortunately you can't reference the Group from the Create a User test step since the pill is a reference to the sys_user table, but it would be awesome if ServiceNow could find a way to open this up, as it would be one less piece of hardcoded data within tests.



Now I'll do some querying on the Incident itself, first I used an Open an Existing Record test step to point to the Record Insert test step I just added, and then a Field Values Validation test step:




Running the test I can see my field values were input, and the dot walked value for Caller.Manager is also displaying on the form without having to hardcode any user values for the Incident record itself.


Working with Approvals


Next I'll add an Approval record and then Impersonate the ATF Approver User to Open an Existing Record and click the Approve UI Action. This is a super simple proof of concept, but you can see the power behind using it in things like Change Management or Workflows that use Group approvals. You'll notice I unchecked Enforce security, this is because at this point in the test I'm still running as the ATF Fulfiller User. I could Impersonate an Admin to do this without bypassing security, but since this is a proof of concept and more than likely Approvals won't be created ad hoc in testing I just bypassed it for now.






Notification Testing


Finally, let's throw in a Notification Test Step since we added an email address to our ATF Caller User, to ensure Incident notifications are going out to that specific email.



Takeaways


I hope this post helped to display the power of setting up some simple test data when working with users within tests, and how that data can be used in a variety of testing scenarios. I love how you can include as many attributes as needed per test when working with users, or none at all if you don't need them. Using these steps ensure you have the user data you need in every instance you choose to run ATF tests in. I would love to see the dot walking functionality expanded in future releases such as inputting Assignment Groups from a Create a User test step, and expanding the dot walking functionality to Record Insert/Record Query test steps, so specific field values can be validated without having to hardcode them in. It would also be great to validate fields such as dynamic short descriptions since a lot of Catalog Items use them, such as Short Description is/contains [Record.Short Description] as this would help test creators ensure their tests are more dynamic and reduce error when working with specific values in multiple instances.


Resources


ServiceNow Product Documentation: Available quick start tests by application or feature

ServiceNow Product Documentation: Automated Test Framework design considerations

216 views0 comments