You've probably experienced many situations, in which you've cursed the work tools, which are an inevitable part of your everyday work. Just like a butcher needs a sharp knife, a courier needs a mobile van and a bricklayer needs a good-quality mortar, the developer of automated tests also needs to have the right tool for his job – a tool which is a good fit for the tested object and everyday work..

Not that our “automation engineers'” previous tool wasn't doing its job, on the contrary, a few years ago it was an ideal solution. As it sometimes happens, the years have passed and the tool has lost its effectiveness. In the following article we would like to describe our beginnings, as well as the migration process of our previous “backend” test automation based on the Micro Focus UFT to very popular and by the community well-liked tool – to Cypress.

THE INNOVATIVE FRIDAYS GAVE A GO TO THE NEW TOOL

The format of the so-called innovative Fridays has become the Cypress' starting line. The first test concept designed in this tool was created on this workshop, which is organized on our project regularly once in a quarter of a year. The topics are collected in advance, while everybody can join either with their own idea or just join the already existing idea and a group, which then develops this idea and works on the first solution.

Some people involved in the project considered the Cypress an appropriate alternative already for a long time. The developers from one of the “scrum” teams had even begun to use it in isolation, but most of the test automation engineers were using the previous tool. Gradually, four more teams joined the first team, so the new tool was gaining even more space.

THE PROCESS AND THE REASONS OF CHOICE

The migration was specific and unique in that only teams working with the system application layer were involved. Our project is quite huge and most people within the project work with the functional and integrational testing of one or more microservices (Spring Boot). That's why it was necessary to choose a universal tool designed for the test automation. Even though the Cypress is presented mostly as a UI tool, it doesn't miss out on elements, which enable to cover the whole process from the database through the REST service, “messaging”, SOAP communication to the already mentioned web presentation layer.

Moreover, the Node JS, in which the Cypress operates, provides the modularity by NPM, which is a public package manager for JavaScript providing a wide palette of plugins. As application layer testers, we were offered an opportunity to “misuse” one of our developers' unit test tools, but we decided to keep the decentralized set-up of the project. In practice, it means that as developers of automated tests we were partly separated, despite our close contact with our teams (mostly the developers).

PREPARATION OF BASIC FUNCTIONALITIES

In the preparation of Cypress for its atypical role for web services testing, some questions have emerged, to which we needed to find the suitable answers.

HOW MANY SEPARATE PROJECTS DO WE USE?

In case it's a small and easy application, the solution is very easy, thus one Cypress project for everything. But our situation was different. Since each of the microservices represents a separate application with a bunch of functionalities, there could be a problem with the code sharing, if we created a separate Cypress project for every microservice. Moreover, the work would be slowed down, because every team manages multiple microservices, and the tester would have to switch projects constantly.

We thought about a different approach, and thus to create one big global repository with all the tests for 20+ microservices. However, the final solution was the middle path. We divided the applications to clusters, which got the dedicated Cypress project. In practice, it means that every team has one repository, because it handles a group of “backend” applications, which have the common technical denominator.

HOW TO SOLVE REPORTS, WHICH WE WANT TO SAVE AND ARCHIVE?

As the test management tool we were using ALM, which is compatible with UFT, but difficult to integrate with Cypress. We temporarily chose the path for the reports' creation with the help of the Mochawesome library, which generates an HTML report after the test execution. We save the HTML reports to Gite together with the tests in a separate folder, and we add the report to the particular user story by link.

IMPLEMENTING CI/CD IMMEDIATELY OR LATER?

Nowadays is the integration of automated tests to “the CI/ID pipeline” very popular, however we decided not to use it in our project. The main reason is the way of code testing by our developers. Besides the unit tests, they also create the so-called system tests, which are integrated in the “build pipeline”. These are very similar to our function tests, but in comparison with our test, they use less testing scenarios. That's why we decided not to apply another testing layer.

HOW TO APPROACH THE MYSQL DATABASES?

For an easy access, we used the NPM package “mysql”.

HOW TO MUTUALLY SHARE THE URLS, LOGIN AND ACCESS DATA?

We used the existing configuration server, which serves for the Spring Boot applications. We access it with the help of other NCM package ("cloud-config-server"), by which we always have all the required access data, which are in case of change updated by our developers.  

EDUCATION PROCESS AND MIGRATION

After solving the technical matters, we started to share the knowledge and to plan the migration. The process of education and sharing of the know-how went very well, even though we have been using the low code environment 90% of the time before. The developers of automated tests got accustomed to Cypress quite fast. The migration plan was a bit more difficult. Already from the beginning, we anticipated that such number of tests won't be that easy to migrate, as the Cypress is a completely different tool. And so the only thing left for us, was to start planning gradual manual migration of one test after the other. The numbers were surprising for everyone. There were lots of tests, that's why every team got the space to optimize its projects and to estimate the migration time. Based on all the teams' estimates, we decided to migrate gradually quarter of year by quarter of year and develop new tests in the meantime.

The migration itself went smoothly, and in the moment we use the UFT only to gain the required information from the previous test to create a new one in Cypress.

A GLIMPSE INTO THE FUTURE

After some time, we found out that not every decision of ours was correct. For example, by separating the repositories we caused that every developer of automatized tests is doing their own solution implementation in Cypress. However, the most important is, that the whole situation is significantly better than it was when we were using the previous tool for test automation. Cypress is much more effective and its biggest advantage is the time saving.

Autor: Jozef Kováč

en_USEnglish