Testing With Cypress Testing With Cypress
March 24, 2023
Ever since we’ve been using (a versatile and reliable visualization framework for large-scale datasets based on WebGL), we wanted to challenge ourselves by attempting to provide a way to test what the map renders to the users and if the data match our expectations. Given that Cypress is pretty much the ideal tool to use for this type of end-to-end testing, we initially performed an analysis of what exists, what the limitations are (there are quite a few, unfortunately), as well as whether or not it’s looking promising (long story short: it definitely is!).

When we look at a codebase of any web application, we find several interesting points. First and foremost, at least 50% of all app functionalities are written specifically for visualizing and interacting with 2D or 3D objects on a given map. If we would want to test how the app, map, or those objects behave, there already is an officially supported method –'s SnapshotTestRunner– which we find to be quite insufficient, since it only allows testing in a “read-only" mode. If your app, like ours, supported features such as drag-and-drop, object selection, live object editing, then you’ll come to the conclusion that something more advanced than snapshot testing is required.

Another side-effect of not being able to test such a web app is extremely low code coverage. Simply put, when there’s no possibility to write tests covering those advanced features mentioned above, nobody can say their app has good code coverage.

Our QA Tech Stack

As one of the most versatile and adaptable solutions available, Cypress is what our QA uses to implement end-to-end tests. That also applies in our application, and since the application itself is very large, the other 50% of the functionalities were already covered by Cypress tests (those that don’t deal with any of the features).

At that point, we wanted to get into how we might implement all those advanced features without having to setup nor use any additional testing frameworks, so that we wouldn’t have to worry about any overhead.

Current State – Why Can’t We Test in Cypress?

The answer to this question lies in the very simple fact that uses WebGL technologies and features under the hood. With such an implementation strategy in mind, we know that none of the elements we see on the screen are actually DOM elements.

The elements we want to render on a map are actually going into a canvas element, which is what makes retrieving them quite difficult. Once all 2D/3D objects are rendered on the canvas (scene), they are hidden away and inaccessible (in other words, you won’t be able to see them even if you explicitly searched for them via the Inspect Element window). When that is the case, not even Cypress can fetch the objects and validate their existence.

Cypress e2e test runner window

What’s Missing / What Do We Want to Achieve

Interactive features of our app include actions like enabling / disabling a layer (group of objects) in the scene, moving an object around the scene, hovering object to display a tooltip. Validating those features automatically means we need to get information whether an object is currently displayed in scene, where it’s displayed, in what shape, color, etc. Generally speaking, we needed a way to introspect a scene, a way to find an object (cy.get alternative) and get its properties.

The Solution – in Theory

From code perspective introspecting a scene can be seen as getting access to WebGL context, its internal state and operations with it. Unfortunately, plain WebGL API is rather too low level. By working in a more business-oriented way than research-oriented way, we considered to limit the solution to a higher level – This way we were able to create a working prototype and see the results much earlier.

In general, it’s good practice to cover production code with tests, but what’s even more important is that tools used to write tests also work as intended.

Our main assumptions were:

- The library and its related ecosystem are already tested and work 100% correct.

- If receives same input, it will produce same output.

Having established the baseline, we look at the higher level – an interaction between the app and the API. The solution relies on public API offered by and uses a bit of internal API of to retrieve the layer hierarchy. Now, if we inject a piece of code in the middle of and application, we should be able to observe how the application is manipulating’s input and retrieving state to check all objects’ properties. Practically, we can achieve this by injecting props, intercepting deck instance, building all necessary internal structures for faster object finding, and finally export utility functions to operate the system. Those exported functions are the core value of our plugin, an API which any QA engineer can use in their automated tests.

The Solution – in Practice

Our work towards getting this up and running began by writing the “backend” part, which meant providing a plugin inside the source code that would function as a middleware between our custom app and itself. It’s supposed to receive the app’s required properties, process them by setting up proxy event handlers, and return new props that eventually get forwarded to

That part was achieved by providing Test IDs to all layers we render on the map. If you’ve ever debugged layers, you’ll know that there’s no such property as testId, but if you forward a custom TypeScript interface to the layer with that new string property, you’ll be able to write getters and setters without problems.

After this was ready, we had to think of a way to export something to the browser’s window object so that Cypress can access the rendered data. Therefore, we created an instance of our custom DeckInspector class, which we’re exporting once the map renders with its data.

From that point on, Cypress can access the class functions by calling window.deckInspector, and the rest is up to the testers. Some of our successfully implemented and tested functions provided by our DeckInspector class are getElementByTestId(testId), zoomTo(element), getText(element), and getLayerHierarchy(), which fetches the complete hierarchy of all layers visible on the map. Once the plugin is ready, functions for fetching specific layer features will also become available, (such as dglFillColor or dglCenter).

Open Points

Despite this being our initial proof-of-concept version, we haven’t noticed a lot of unfixable open points. The two biggest issues for us were dragging and dropping elements onto the map / canvas, as well as fetching the coordinates of a rendered layer’s center point. Tooltips, which are also an open point, have not yet been covered or inspected in terms of whether they are testable.

Last, but not least, once the plugin becomes publicly available, test coverage data of the plugin itself should also be provided.


We’ve only scratched the surface, and yet we’re very optimistic about the future of this approach, as well as how much potential it offers now, despite its limitations! We hope you enjoyed reading this as much as we enjoyed researching and writing about Cypress and!

Stefan is a medior React developer and former content manager & technical SEO specialist from Serbia. Enjoys playing squash, having fun with friends, visiting new places, and writing interesting content about topics close to his tech stack. Dank memes enjoyer. "You miss 100% of the shots you don't take - Wayne Gretzky" - Michael Scott.

Article collaborators

SABO Newsletter icon


Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

About SABO Mobile IT

We focus on developing specialized software for our customers in the automotive, supplier, medical and high-tech industries in Germany and other European countries. We connect systems, data and users and generate added value for our customers with products that are intuitive to use.
Learn more about sabo