ATF is ServiceNow’s automatic testing framework. Like all the ServiceNow tools, it’s OK. These are some notes, in no particular order, on ATF.
How we implement an application will drive what types of tests we create. Generally, we assume the following design conventions when talking about tests here:
Put all application logic in Script Includes - Things like UI actions should generally just instantiate a Script Include, call a method and handle errors/output/redirection/etc…
Script Includes (or their functions) should not use any global objects (e.g. if you need the current user, take a
user as a parameter rather than using gs.getUser() in the method itself). To the extent that it is possible, they should
be “pure”:
The definition of a pure function is: The function always returns the same result if the same arguments are passed in. It does not depend on any state, or data, change during a program’s execution. It must only depend on its input arguments.
There are 2 general types of test to think about with ATF. Generally, they are UI tests run with an automated web browser and unit tests.
Tests should be named something that makes sense, and include a description of what the test does in the main test record.
Tests should not rely on data that is specific to the system. If specific things are needed by a test (such as associated records, users, or anything else) the test should create it.
For testing users/roles/permissions (which is a must) create the user with the proper role(s) in the test.
You can specify the role when creating the user, and this makes moving tests across systems much easier, and anyone that has to maintain the test (including the author) will be much happier.