A new adventure has just begun!
GSoC 2021: E2E Automated Tests for the OpenMRS 3.0 RefApp
“More than the act of testing, the act of designing tests is one of the best bug preventers known.”
-Boris Beizer
As a result of the Microfrontend Team’s tireless efforts, OpenMRS will soon have its new edition “OpenMRS 3.0”. Most of the MFE applications have their own unit tests and integration tests. Those tests will take a small part of the application and assess that part in isolation. However, even the small parts of the application work fine, It does not guarantee that they will work together as a group. This is where the E2E tests (End-to-End Tests) additional test layer comes into play. The goal of my this year’s GSoC project is to set up E2E tests that automate realistic User Workflows to ensure that they work as they should.
I spent some time getting acquainted with it as it was the first week of the project. I had my first call with my mentors; Joseph Kaweesi and Brandon Istenes to clarify the project and plan out the rest of the week. Then I joined the QA Support Team and the Microfrontend squad, thinking that those were the places where I could share my work.
Since this is the very beginning of the project, I thought I’d explain the project’s background briefly.
End-to-End (E2E) Tests?
E2E tests verify complete system flow and ensure the application behaves as expected. Moreover, E2E tests simulate real-world scenarios, which allows seeing how a real user will interact with the application.
As an example, It can be something as simple as the login page of the OpenMRS. The test would involve:
- Opening the login page of OpenMRS in a browser
- Typing the username and password
- Ensuring that the user has successfully logged into the dashboard
Fig. 1. Shows a simplified version of Google’s test pyramid. Google suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. [1]
Types of E2E tests
There are two types of E2E testings, manual E2E testing and automate E2E testing. In manual testing, a business tester acts as if he or she were the customer on multiple devices and screen sizes as needed. The tester will follow the same process as a normal user who would decide whether the application’s specifications are being met.
On the other hand, automated E2E testing has the same aim. Just that automated testing has more advanced functionality that a human tester would not be able to provide[2].
As previously mentioned, manual testing entails a tester manually executing experiments. Bad testing can be caused by human error. Since automated E2E tests run automatically without a human, it is more accurate in many situations. Moreover, automated tests save time in the long run as it only needs an effort at the beginning [2].
The following are some of the major automated E2E testing frameworks.
- Cypress
- WebdriverJS
- Protractor
- WebdriverIO
- NightwatchJS
- TestCafe
Upon them, Cypress seems to be a suitable framework considering the time and effort required to set up the environment, run tests and get reports.
Cypress
Cypress is a Non-Selenium-based framework where it does not need additional drivers to interact with browsers. The test cases can be defined using javascript within the project and can be run with Cypress Test Runner’s tool. The tool will open the selected browser and run the test automatically.
One of the best features of cypress is the time travel functionality. It allows testers to take snapshots as tests run, which allows them to see what happened in each step. Furthermore, it allows debugging the tests using the developer tools of the browser. It helps to identify why the tests are failing. Cypress supports Chrome, Firefox, Edge, Electron, and other chrome family browsers[3]. Moreover, it can be used together with a well-known testing tool named Cucumber.
Cypress Cucumber Integration
Cucumber is a testing tool that supports Behavior Driven Development[4]. It provides a method for writing tests that everyone, regardless of technical skills, will understand. Cypress Cucumber integration can be done via a plugin named “Cypress Cucumber Preprocessor”. The plugin allows running tests from cucumber feature files[5].
The main objective of the project to set up tests using Cypress and the Cucumber test engine framework. The tests will automatically run against the UI, based on realistic user workflows. The results would be indicated on a shared Repo ReadMe so that no one misses failing tests. Hope I could contribute to OpenMRS this summer to make it better!
References
[1] “Just Say No to More End-to-End Tests,” Google Testing Blog. https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html (accessed Apr. 13, 2021).
[2] “A Comprehensive Guide to End to End (E2E) Testing | by Perforce,” Perfecto by Perforce. https://www.perfecto.io/blog/comprehensive-guide-end-end-e2e-testing (accessed Apr. 13, 2021).
[3] “Why Cypress?,” Cypress Documentation. https://docs.cypress.io/guides/overview/why-cypress (accessed Apr. 13, 2021).
[4] “Introduction — Cucumber Documentation.” https://cucumber.io/docs/guides/overview/ (accessed Apr. 13, 2021).
[5] “cypress-cucumber-preprocessor,” npm. https://www.npmjs.com/package/cypress-cucumber-preprocessor (accessed Apr. 13, 2021).
