Automated Testing of Webix UI With Playwright

Writing tests is a fundamental part of software development. While creating high-quality software solutions, testing helps minimize errors and reduce overall costs, especially when applied early. There are various types of software testing, and automated testing is one of them. Like any other tool, it has its pros and cons. Sometimes, all your efforts will result in wasted time and money. However, it can significantly improve the app’s stability when done right, resulting in better user satisfaction and increased ROI.

Today, we’ll consider how you can apply automated testing to web apps built with Webix. Our primary goal is to demonstrate the basics of using it in practice. To do this, we will start with a very simple test and smoothly move on to working with Webix widgets. It’s up to you to decide if this approach is worth your time.

Writing a Simple Test With Playwright

At XB Software, we’ve been working with the Webix UI library for almost ten years since its beta version was released. We used various testing tools at different times, including Selenium and Puppeteer. Lately, we mainly use Playwright for end-to-end (e2e) testing. One of the main reasons is that it allows us to work with Chromium, Firefox, or the WebKit web browser engine using a single API. Also, it supports all major operating systems, such as Windows, Linux, and MacOS. To show you how Playwright can be used for automated testing, we’ll use the Webix Admin App Demo:

Source: Webix Admin App Demo

The demo is available on this GitHub page, where you can also find instructions for downloading and running it. After downloading the app, the next step is to install and initialize the Playwright test framework. You can do it using npm by running this command in your terminal:

It’ll create the following files:

The test-examples folder contains a demo application for testing. What we need to focus on right now is the tests folder. Here, we’ll work on our e2e tests. First of all, let’s open the example.spec.ts file and import test environment variables:

Now, we are going to write our first test. Let’s start with something relatively simple. It’ll check the page’s name as shown in the browser tab. Run a local server for the demo application and use the following code:

Most tests should start with the URL address to ensure they can interact with page elements. Now, we can run the test using this command:

You should get the following result:

The last string shows a command you can run to get an HTML page containing the test report. In case some errors occur during the testing, the report will open in the browser automatically.

Read Also Why Software Testing Plays a Key Role in a High-Quality Software Product Development

Testing Multiple Page Elements at Once

Let’s see how we can work directly with Webix UI elements. The main page of our demo application has a navigation menu bar on the left. It allows users to switch between different app pages:

In our second test, we will check if all these menu items are clickable and if the mouse hover action works correctly. To find elements on the page, we’ll use the locator() method, passing the following selectors into it:

• .webix_sidebar, a CSS class related to the sidebar component;
• .webix_tree_item, a CSS class corresponding to the tree component element.

Next, we’ll use the all() method to get an array of all elements containing the above selectors. We can use the click() and hover() methods for each of these elements by iterating over the array’s contents. Here’s the resulting code:

In the terminal, we can use the command that we’re already familiar with to run the test and check the results:

This time, we run more complex tests, so it makes sense to check the report. It’ll contain all tests we wrote for three different browser engines. For example, you can check the “dashboard” test report for Chromium. It shows that 8 menu items were found, each successfully tested for clickability and response to the mouse hover action:

Testing Forms And Options Selection Controls

Let’s get things more challenging and try to work with forms. Our third test will use the getByLabel() method to check whether the field on the Forms page can be filled:

Here’s how we can find and fill the Notes field:

The fourth test works with the Tables page. It implements the scenario of opening the app in Chromium and selecting an element in RichSelect to filter the contents of the bottom right table. Also, it makes screenshots of the page before and after applying filters. For this purpose, we can use the screenshot() method:

After we run the test, a new folder named testScreenshots will be created in the project folder. Inside, you’ll find two screenshots with the names we set in the code earlier, namely tablesScreenshotPrev.png and tablesScreenshotNext.png. We can compare them to check if the app works correctly:

Table before applying filters

Table filtered by given value

Lastly, the fifth test returns us to the Forms page. Here, we’ll check how adding and removing items works with the Multicombo control. Also, we’ll test if changing data in Combo and Textarea controls works correctly:

After we run this test, we’ll get screenshots named formsScreenshotPrev.png and formsScreenshotNext.png, which will help us ensure the app functionality is correct.

Conclusions

Webix provides access to a few dozen simple widgets. On their basis, a wide variety of complex widgets are built, including File Manager, Scheduler, Pivot, etc. Despite such diversity, you can use a single approach to writing automated tests. Today, we covered the basic principles of testing Webix apps using a demo built with such widgets as Form, Menu, DataTable, Checkbox, DataPicker, Toggle, and others. Testing apps consisting of complex widgets follow the same pattern. With these skills, you can cover any Webix application with automated tests, integrate them into your CI/CD process, and reduce the number of bugs in production to a minimum.