On a busy day at Nitor Infotech, we were working on a business use case based on geospatial data. Unlike ordinary spatial data, geospatial data is information that describes objects, events, or other features with a location on or near the surface of the earth. Geospatial data normally involves huge sets of spatial data collected from various sources in differing formats. Vector data and raster data are two primary forms of geospatial data. (End to end testing coming up!)

Our application is based on a leaflet – a JavaScript library for interactive and Geospatial Information Systems. There were a few specific geospatial features which we wanted to automate so that we can find early bugs and gain confidence over build. The ability to automate rendering of various kinds of geo layers on the map and making sure they are laid out at the correct location based on the CRS was a unique challenge.

While working on automation testing for a web application which is heavily based on geospatial data, we can face multiple challenges including:

• Complex data: Geospatial data can be complex, the data can be in different formats such as vector data, raster data, 3D data, and more. So, testing applications that use this data can be challenging.
• Real-time data: Geospatial-based applications often involve real-time data, and this can make it difficult to test the application as the data is constantly changing.
• Map rendering: Testing the rendering of maps can be challenging, as the maps need to be rendered accurately and quickly. This can be difficult to achieve in an automated testing environment, especially if the maps are interactive or use advanced features such as 3D rendering.
• User interactions: Testing user interactions with the maps as there are many ways that users can interact with the maps. This can include zooming, panning, and clicking on markers and other map elements.
• Data privacy and security: Geospatial-based applications may handle sensitive location data, and it can be challenging to ensure that this data is handled securely and in compliance with data privacy regulations.
• Maintaining test data: Geospatial data is often subject to change and therefore maintaining test data is challenging, as test data needs to be updated regularly to reflect the current state of the application.

To overcome these challenges, we have used specialized libraries to generate geospatial and real-time data. We also used a combination of manual and automated testing to ensure that the application is thoroughly tested.

For a test automation tool, we choose Cypress as it is comparatively fast and due to its native support with JS, we can use all the libraries which are used in actual development. Cypress is an automated testing framework that is primarily used for web applications. While it does have features that make it well-suited for end-to-end testing and integration testing, it does not have any specific built-in support for geospatial data visualization or analysis.

However, Cypress can be used to test geospatial-based applications by automating the end-to-end testing of the geospatial-based functionality within the application. For example, Cypress can be used to:

• Test the input and display of location data
• Test the functionality of maps and location-based services
• Test the integration of geospatial-based functionality with other components and services

Cypress can also be integrated with other tools and libraries to test geospatial-based functionality, such as testing the display of maps using leaflet or Openlayers.

What makes Cypress unique?

• Most end-to-end testing tools are Selenium-based whereas Cypress runs in the same run-loop as your application.
• Driver binaries are not needed in Cypress automation testing and execution occurs on the real browser.
• Cypress has an in-built wait for requests feature that eliminates the need to configure additional waits.
• Cypress tests anything that runs in a web browser.
• Cypress tests are only written in Java Script and Type Script.
• Cypress automation testing lets you change code and execute the same on the fly.
• Cypress can do BDD & TDD testing with full end-to-end tests.
• Cypress provides dashboard support for detailed reporting.
• Cypress supports parallel test execution.

If you want to know more about deploying Cypress hybrid automation solutions, download our whitepaper

For geospatial features, it was crucial to analyze and test each step. We have chosen Cypress as it provides time travel, and we could hover on each step to look on map what happened during execution. Many times, we need to render geo layers on map. Using Cypress automatic waiting we could handle sync issues and assertions made sure that we tracked the right scenarios. Cypress helped us in verifying location-based layers correctly and our tests were too fast, consistent, reliable, and flake-free.

Setting up Cypress automation testing

Here is some sample code:

Here are a few commands we used to perform the automation tasks:

1. Create a spec file – It and Describe are Mocha methods, providing a way to keep tests easier to read and organized.

2. Hooks – There are some hooks that allow setting a condition before and after tests run.

3. Querying a DOM element

a. You can simply query elements using cy.get().
b. You can also traverse to a particular DOM element using HTML tags.
c. You can find an element in the document containing the text using cy.contains(‘text’)

4. Timeout for missing elements

a. Cypress better reflects the operation of actual web applications by wrapping all DOM queries in robust retry-and-timeout logic.

b. The following configuration setting enables global timeout setting: defaultCommandTimeout.

c. Using cy.get(“locator”, “timeout:12000”), you can also set a specific locator’s timeout.

d. Interacting with elements – We can chain multiple actions using cy.get() and use blur (), focus (), uncheck (), select (), dblclick(), rightclick() commands to interaction with DOM elements.

5. Asserting about elements

a. Assertions are commands that help you to explain the required state of the application.

b. Cypress will automatically wait until your elements reach this state or fail the test if the assertions do not pass.

Here are some images of map layers-shape files for – Draw a polygon on map with edit, save and delete features. The wells under this shape should get extracted.

We are certain to discover that when we compare the efforts of manual testers with those of this test automation framework:

• Test scripts were more reliable as manual test reports were prone to error.
• Test scripts were executed in comparatively less time for all features than manually checking each feature one by one. The scripts handled all user centric map interactions like zoom in/out, drag/drop, draw etc.
• Test scripts can be processed in batches for all categories of features on map whereas we need to check every category of feature one by one in case of manual execution.
• Test scripts written once were used to trigger an execution suite everyday unlike daily investments of manual efforts.
• To write test scripts in Cypress, we needed good programming knowledge and considerable time to prepare the framework, whereas a good understanding of the application was required to perform manual testing.

Finally, if you want to build an automation framework that works with development and deployment, a PoC on Cypress is worth a try!

Write to us with your thoughts about this blog. Also visit us at Nitor Infotech to learn more about our big data offerings.