Introduction

This article will discuss the use of Selenium-Webdriver, which is a tool for automating the actions of a web browser on Node.js platform.

At one of the projects, we had the task to develop Web UI autotests. One of the wishes was to run tests on the side of the frontend developers using only Node.js features, without using third-party applications.

Historically, Java and Python were considered the standard for test automation for a long time. Therefore, if you conduct a survey among automation engineers, then with a high degree of probability they will choose one of these programming languages.

Why is this article important? Indeed, on the Internet, you can find many articles and examples of how to implement UI tests using Selenium-js. However, when they are studied in detail, it turns out that the examples in these articles are quite simple, while examples using PageObject model are much more difficult to find. Therefore, if you want to know a little more, let’s go ahead.

About the difficulties of choice

The key requirement that confronted us was that autotests should be written on Node.js. Everything else could be chosen within wide limits. The first choice on a difficult automation path was the choice of a test framework.

Mocha

A huge number of libraries have been written for Node.js, so in order not to get lost in this variety, we have allocated several frameworks for ourselves:

  • Cucumber is a popular open-source BDD framework that uses Gherkin language to implement tests.
  • Jasmine is a popular BDD framework for testing JS.
  • Mocha is a JS framework that makes it easy to test asynchronous code in a Node.js module or browser application. Tests in Mocha have improved exception tracing quality and can be run in series.
  • Protractor is the popular E2E Angular framework based on WebDriverJS.

Experience with Java in this area pushed us to look for a similar solution to JS, and we chose Mocha. Therefore, it was decided to refuse of using other more exotic frameworks.

Using Mocha, we get the necessary minimum and nothing more. And besides this, Mocha is one of the most popular Node.js frameworks with a fairly active community and a lot of documentation. But with all the advantages, it also has a drawback – this is the lack of asserts.

Therefore, it was decided to use the third-party Chai library for checks. Connection is simple – you need to enter only one line, and a bonus to this will be the ability to use any of the assertions styles: assert, expect, should.

Selenium-webdriver

Since at the stage of choosing the framework we refused to Protractor, then we had to choose the “communication mechanism” of the tests with the browser. And here, too, JavaScript can boast a variety, here are the most basic candidates:

  • Selenium-webdriver is classic Selenium in JS.
  • WebdriverIO is essentially a high-level wrapper over Selenium-webdriver.
  • Nightwatch.js provides a separate testing framework, which has all the necessary tools: server, asserts, etc. Moreover, it can be used as a completely independent solution, or as part of various solutions.

The choice fell on Selenium-webdriver, since this is a classic solution for this task, the methods of working with which are practically the same as those in Selenium on Java.

Code examples

In this section, samples of code executed on specified technologies will be given.

BaseDialog

This class is a part of PageObject model of the tested application. It describes the basic functionality for any dialog box of the tested application. Also, this class is inherited from BasePage, which describes all the basic functionality for working with any web elements. Each web element which we want to interact with in the tested application should be reflected in this model (pages, tabs, button dialogs, etc.).

SaveDialog

This class is also a part of PageObject, it implements the base class of BaseDialog. As can be seen from the screen, in the new dialog, the processing of one more “Save” button is added.

The base class of BaseDialog dialogs has many implementations (for example: error dialog, delete dialog, etc.).

BaseSteps

In this screenshot, we see a part of BaseSteps class. This class contains a set of common methods that will be needed to implement any scenario (for example, login to the application, logout, etc.). The class is the basis of the steps layer.

Special cases of steps are inherited from this class, so the steps layer also represents a separate OOP model.

TestExample

Here, you can evaluate the approximate form of a regular test performed using PageObject.

As you can see in the screenshot, the test itself is very compact. It clearly shows the input parameters, some action with them, and at the end one control check that the data is formed correctly.

Conclusions

Can Node.js tools be used for web UI testing? Of course, they can, but you need to be prepared for various kinds of difficulties, such as:

  • Asynchrony – it could be said that the methods in the tests get ahead of themselves and check your data before you enter it. It is solved quite simply – you just need to get used to it.
  • Limited support of OOP in JS – you periodically have to go through the rigmarole, because one of the objects does not show methods.
  • Due to problems with building OOP models, it was not easy to get PageObject model to work correctly.
  • Although mocha has the ability to work with tags, there is not as much flexibility as you like. This is not a question to all JS, but only to the framework.

And here is a list of the benefits we got using this approach:

  • All code can be in one repository, and developers will not need to install additional tools such as Python or Java to run tests.
  • If you need to use some functions from the application, their connection can be a fairly simple action.
  • The interaction between the team of developers and testers is simplified, if necessary, developers can connect to the test’s implementation.

Useful links