UI Test Automation Overview

   MaestroThe UI design product.  |   Form Builder |   22.04 This feature was updated in 22.04.

Many customers choose Journey Maestro because of the speed to market advantages the platform offers. Underpinning speed to market is a successful DevOpsDevOps is a software development methodology that combines software development (Dev) with information technology operations (Ops). The goal of DevOps is to shorten the systems development life cycle while also delivering features, fixes, and updates frequently in close alignment with business objectives. strategy and the key to DevOps is a comprehensive regression test suite.

Maestro provides the compelling set of features that enables UI testers to dramatically accelerate the creation and maintenance of UI test suites for forms as well as solving one the most pressing issues of web-testing - non-deterministic testA test is non-deterministic when it passes sometimes and fails sometimes, without any noticeable change in the code, tests, or environment. Such tests fail, then you re-run them and they pass. Test failures for such tests are seemingly random. results.

Before we delve into details, we recommend becoming familiar with a WebDriver based test automation framework and Maestro debugging techniques.

Selenium & WebDriver

Talking about UI test automation, we assume you use a WebDriver derived UI automation framework. We also provide all examples for SeleniumThe Selenium testing software tool is used to automate tests across browsers for web applications. It's used to ensure high-quality web applications — whether they are responsive, progressive, or regular. Selenium is an open-source tool. in JavaJava is a programming language that produces software for multiple platforms. When a programmer writes a Java application, the compiled code (known as bytecode) runs on most operating systems (OS), including Windows, Linux and Mac OS. Java derives much of its syntax from the C and C++ programming languages.. Although that may not be your company’s preferred UI testing framework, the concepts are valid for any WebDriver derived framework.

WebDriver is a standard maintained by the Worldwide Web Consortium (W3C), which defines it as follows:

• WebDriver is a remote control interface that enables introspection and control of user agents. It provides a platform- and language-neutral wire protocol as a way for out-of-process programs to remotely instruct the behavior of web browsers.
• Provided is a set of interfaces to discover and manipulate DOM elements in web documents and to control the behavior of a user agent. It is primarily intended to allow web authors to write tests that automate a user agent from a separate controlling process, but may also be used in such a way as to allow in-browser scripts to control a — possibly separate — browser.

In short, it allows for the remote control of a browser application, you write tests that ‘drive’ the web application.

It is beyond the scope of this document to explain the intricacies of testing, but a short overview of the key concepts is appropriate.

UI Testing Key Concepts

To control an element in the browser, you must locate it in the browser’s DOMThe Document Object Model is a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree.. Since the original Selenium framework, on which WebDriver is derived, was written in JavaScript and ran in the browser, locators closely match familiar ID, CSS and XPath based selectors. For example, all of the following Java code snippets locate an element and then click on it:

• driver.findElement(By.id( “element-id“ )).click();
• driver.findElement(By.cssSelector( “#element-id“ )).click();
• driver.findElement(By.xpath( “//*[@id='element-id'“ )).click();

Each call follows the same structure:

• driver - is the WebDriver, an object that provides the means to connect to, introspect, and control a browser session.
• findElement - is a method that finds the first element using the given By locator or throws if no element can be located matching the locator. The return value is a WebElement that provides methods to query and interact with the remote DOM object.
• By - is a class that provides the means to lookup an element in the DOM by a specific locator scheme. As noted, conceptually, these should be familiar with anyone who uses CSS Selectors. In each example we select by the element’s ID but, obviously, this isn’t how cssSelector and xPath would typically be used. Note that By.name, By.tagName, By.linkText, and By.partialTagName are also supported, but we do not need to use them.
• click() - is a method on the WebElement that clicks on the element if it is visible and has a height and width of greater than zero. (Selenium is a test framework that tries to behave as a human would: a DOM element may exist but not be visible.)

To create a test, every element in the DOM must be identified and then code written that introspects and interacts with these elements, asserting that the correct behaviour is observed.

Issues in UI Testing

Martin Fowler popularized the idea of the Test Pyramid that was first espoused by Mike Cohn as a way of thinking about different kinds of automated tests. This is illustrated below.

This neatly captures the fact that UI testing is costly and slow. From the code examples above, one reason why this is true should be obvious: identifying elements in the DOM is time consuming and fragile. During development, element types change, element IDs change, element structure in the DOM changes, and CSS changes. Changes introduce non-deterministic results into test suites.

To quote Fowler - “Most importantly such tests are very brittle. An enhancement to the system can easily end up breaking lots of such tests, which then have to be re-recorded. You can reduce this problem by abandoning record-playback tools, but that makes the tests harder to write. Even with good practices on writing them, end-to-end tests are more prone to non-determinism problems, which can undermine trust in them. In short, tests that run end-to-end through the UI are: brittle, expensive to write, and time consuming to run”

Non-deterministicA test is non-deterministic when it passes sometimes and fails sometimes, without any noticeable change in the code, tests, or environment. Such tests fail, then you re-run them and they pass. Test failures for such tests are seemingly random. failures are the pernicious false negatives – for example, tests that exercise a web based GUI and fail, but fail because of a tiny CSS change.

So much for the bad news. The good news is that using Maestro, most of these problems can be solved:

• Locator instability can be eliminated
• Non-deterministic run time failures can be moved to test build time (with a statically typed language)
• Timing issues can be reduced

Next, learn how to perform UI test automation of Maestro forms.