Text boxes, check boxes, radio buttons, and other elements of forms are fairly simple to deal with when it comes to developing UI functional tests for a web application. But what happens when you want to write a test that verifies that the UI for a web calendar is working?
You are probably thinking that it can be easily achieved with a couple of clicks and validations, which is not only true but also the approach that led to the idea of a handler.
Before you discover how to make your automated QA team very happy, here are some reasons why writing a simple function or just a segment of code that deals with ONE specific calendar is not as scalable. Imagine you are a QA Developer at a company who is developing the websites for airlines A and B and your team is requested to create the automated test suites. Sounds quite easy, you will use the same code in both projects, nothing will need to be changed; until someone shows you the designs of the two web calendars each airline uses in their website.
Beginning with the obvious differences, airline A uses two windows while airline B uses only one; that surely represents a significant change in the code of that first approach. Another difference you might not have noticed is that airline B has a dropdown to change the year of the calendar, so that would mean a slight change in the method used to get the text of the displayed year. Those are two visual differences that will affect the way your bot interacts with the calendar and the DOM will surely surprise you with more.
Now that you are interested, the coding begins!
This handler was implemented in Node.js and uses WebdriverIO as the test framework that interacts with the browser.
You will find out that the framework has two functions ($ and $$) to fetch web elements. However, a hierarchy of classes will be created to manipulate elements, later on you will learn this is so that the handler can easily be able to cover many web calendar designs.
The main class is Element. Here is where, the method to obtain the fetch function is implemented, it has two parameters:
- selectorObject (required) which refers to an object with two properties; the first named selector , is a string that specifies the selector that will be used to fetch the element. The second is index, which is an integer that must be assigned to the object if the fetch result wants to be treated as a single element and not as an array of elements.
- additionalProperties (optional) is an object with any property that wants to be added to the fetch result. The subclasses of the hierarchy use this to manage how some data is obtained from the web elements, you will learn this later on.