Dave Slusher

3 minute read

One of the things that I personally enjoy exploring each release is what has changed in the Automated Test Framework. This is a capability that I love and I like watching it improve to the point where organizations can capture ever more of their testing needs with it. Let’s look at some of what is new in Madrid.

Parameterized Tests

One of the impediments to using the ATF at scale has been the handling of large quantities of test data. This required setting up a test, then duplicating that test with different data which created a lot of test bloat and maintainability challenges. As of Madrid, there are now parameterized tests. This allows for separating out the logic of the tests from the data of the tests and for each to be maintained separately.

By defining the data sets and then associating them with the parameterized test, running the test runs it once for each data set. The results will be recorded once for each run of the test with each data set.

Results are reported for each data set

Custom UI Test Steps

Madrid introduces the concept of the “testable component.” These are standard HTML and JavaScript objects with the characteristics of:

  • being set or clicked by user interaction
  • accessible from the DOM (ie, not created by a shadow DOM)
  • not excluded from customer UI testing (ie, not one that has its own specific test step)
  • accessible to the page inspector (about which more soon)

This allows for testing of interfaces that are not the automatically built ServiceNow form interface. In fact, those cannot be tested via this mechanism because of the reason above - they have their own test steps. What this does allow is all of the UI pages, UI macros, wizards and Service Portal pages that were previously not testable via ATF.

Page Inspector

In order to identify the components that are testable and to get the values needed to test, developers use the new Manual Page Inspector provided by the ATF.

Choose which page to inspect

Begin by selecting the page to inspect. Via radio button, the developer selects whether to inspect a UI Page or Service Portal page. The system will present the catalog of pages that it knows and you’ll select that.

Use the target or list of components to inspect

Once on a page, you have two ways to inspect individual components. You can either drop the target icon onto the component you wish to inspect, or you can select from the list that was auto-generated via the inspector.

Inspecting a component

Once a component is inspected, it shows a list of available attributes and actions. This is the information require to generate the tests for the components. In future posts, we will examine this process in greater detail.

Automated Test Suites via Filter

In Madrid, test suites can now be defined and maintained via the standard platform condition builder. By defining a filter, any test that matches that condition will automatically be included in the test suite. This could be a “contains” condition on the name or as in my example screenshot a tag on the test record. This is definitely a feature to explore in the future because there is a lot of potential to simplify the process around handling test suites at scale in the development and testing process.

Test Suites can be defined via filter

Conclusion

This is not at all an exhaustive list of the interesting features around the Automated Test Framework in Madrid. For those interested in the topic I recommend looking around the release notes to see what is of interest to you. Keep checking back and we will have more information in the future as we post about ATF and other developer-facing features. Don’t forget that Madrid is available now for Personal Developer Instances so get yourself one if you haven’t already.

Happy developing and have fun exploring Madrid!


Comments