24. 12. 2023 Damiano Chini Development, DevOps, NetEye

How We Want to Avoid Breaking the NetEye User Guide (Again)

A few months ago while navigating through our NetEye User Guide we noticed that it had a small bug that caused some words in the right-side menu to be slightly truncated in the particular case where that menu contained some monospace characters.

Well, since this was quite annoying, we fixed it on the fly with some CSS black magic.

All good, until a few days later we heard that mobile users could barely use the NetEye User Guide, with tiles all over the place and annoying horizontal scrolling in many pages.

At this point we wondered, why did we not realize that we were breaking the NetEye User Guide?

The answer was quite simple, which was that we were not automatically testing the NetEye User Guide, as we do for NetEye itself. Clearly also User Guide is a service that must be guaranteed to be available and usable, just like the NetEye product.

Taking for granted that we can’t rely on manual testing of the NetEye User Guide (we would need to test tons of pages on various different screen sizes), we got in touch with our DevOps team and began discussing how we could reach our goal of avoiding breaking the UI of the NetEye User Guide.

How the NetEye User Guide is built

Before diving into how we now test the UI of the NetEye User Guide, let’s give some context on how the user guide is built and exposed. As this blog post explains, every time we perform a change to the content or to the structure of the NetEye User Guide, an OpenShift pipeline is triggered.

The OpenShift pipeline has several steps, like compiling the user guide, building a docker image with it and putting it in production by exposing a container created with the just-built docker image.

How we now test that the NetEye User Guide doesn’t break on mobile

The quite obvious solution to ensure that we would not break the NetEye User Guide again, was to introduce a step in the OpenShift pipeline describe above. This new step should connect to the version of the NetEye User Guide we’re building in the pipeline, and test that the visual part of the User Guide is as we expect. If the GUI is not as we expect it, the pipeline should fail, so that we avoid putting a broken NetEye User Guide in production.

Since the tests we wanted to perform are visual and needed to be reliable, we chose to use Playwright (one reason is that we’re also adopting Playwright for NetEye visual tests to substitute Selenium).

The new step (named neteye-playwright-tests) in the OpenShift pipelines is executed after the build of the NetEye User Guide docker image, so that we can perform an end-to-end test. Inside the neteye-playwright-tests we spawn a Playwright container where we mount the Playwright tests to be executed. The Playwright container then just executes the mounted Playwrights tests by connecting to the version of the NetEye User Guide we are building. The result of the tests is then reported to the OpenShift pipeline, which will block the release of the User Guide in case any test fails.

At the moment when this article was written, our Playwright tests are just ensuring that the mobile version of the NetEye User Guide does not have horizontal scrolling as well as the behavior of menus under various circumstances. But now that we have this new infrastructure, adding more visual tests for our NetEye User Guide will just be a matter of writing a Playwright test.

These Solutions are Engineered by Humans

Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.