Trendyol Coupon Journey: Coupon UI Test Automation Strategy
In this article, as a continuation of the
Trendyol Coupon Journey 1, Trendyol Coupon Journey 2, and Trendyol Coupon Journey 3 article series, I will write about how we automate the web interface tests of the seller center page.
As the Coupon team, the work we do is generally backend work. But also we have a small interface project under our responsibility. This project consists of the screens of the coupon page of the seller center panel used by our sellers.
Sellers use this page to distribute coupons to their customers to increase their sales, give coupons to customers who will follow their stores, or create collect-to-win coupons on their active products that display their store. Sellers can see information such as the collection information of the coupons by their customers or their use in the order on this page. In addition, sellers can see the number of instant collections and conversions of created coupons.
What does the coupons page in the seller center panel mean for sellers?
The example below has a display of a seller’s coupons. The seller can select the type of coupon they want to create first by clicking the create new coupon button on this screen. The seller can create 3 types of coupons. These are:
- Demand: The seller can open demand in order to give coupons to customers who interact with their store or the product categories they are selling.
- Follow To Win: The seller can create follow-to-win coupons for customers who will follow their store. This coupon type appears on the seller’s store page.
- Product Detail — Collect To Win: The seller can create coupons for all of their products, or they can create coupons specific to the category/brand of their products, and these coupons can be seen and collected by customers visiting the products.
After determining the type of coupon, they can choose the collection dates and the usage dates of the coupon. They can also determine the budget and discount of the coupon and request to create a coupon.
Above, I briefly mentioned the capabilities of this interface project and how vendors use it.
Note: To learn more about coupon types, you can start reading from the beginning of the article series.
What were our development areas for testing the seller center panel on our coupon project?
It cannot be said that we made a lot of development in this project compared to our other projects, but despite this, we had some minor, overlooked mistakes after production deployment. In addition, manual tests were slowing our mean change lead time.
In order to prevent such mistakes and to make production deployment with peace of mind, we wanted to write an interface automation test for this project and we included this test automation project in the deployment process of our seller center coupon interface and related projects.
Thus, when the makes any development to the seller center panel user interface project and installs it in the stage environment, the interface tests will be triggered automatically.
The Other Benefits of Automated UI Testing
- Automated UI testing saves time
- UI test automation results in increased test coverage
- Test automation provides the team with a starting point for efficiently executing tests for a great number of use cases without manual effort.
First of all, we produced test cases for this project. Then we wrote the scripts for these tests with Robot Framework
Why did we choose robot framework?
It supports keyword-driven, behavior-driven, and data-driven style of writing test cases. Also;
- Robot Framework is keyword-driven.
- Robot Framework allows the use of Gherkin.
- Robot Framework works for both mobile and web apps.
- The basics of Robot Framework are easy to learn.
- Robot Framework uses a low-code approach.
- Robot Framework is compatible with Windows, macOS, Unix, and Linux.
- Robot Framework supports Jython, IronPython, and PyPy.
- Robot Framework supports all major browsers.
- Robot Framework works well with Appium and Selenium libraries.
- Robot Framework creates strong results and reports
Tests are an important part of the CI/CD pipeline and Robot Framework is a great open-source automation framework to validate a product or a deployment. A lot of bundled library addresses many test contexts like Front-end, API, operating system, and databases with a low level of maintenance. Thus, it is a good candidate for integration and end-to-end tests in a pipeline.
I am sharing a few sample test cases below. These sample test cases contain the most used features by the customer step by step. Please read the two scenarios below to understand the test cases.
However, it has different capabilities that we expect from the test automation project, apart from test running.
These Capabilities: such as running with cross browsers with selenium grid, parallel execution, headless browser testing, reporting, taking screenshots in case of failure, and running on the relative projects’ pipeline.
General guideline:
- End-to-end tests take time, we should use parallelization as much as possible to optimize the pipeline.
- The pipeline status must be in coherence with the status of the tests,
- The report of tests should be easily available, particularly when some tests have failed to understand what had gone wrong.
To start implementing these capabilities, we first needed a robot framework docker image to run the tests and standalone browser drivers for the selenium grid to run the tests.
We used the following docker images for these needs.
Robot Framework:
https://hub.docker.com/r/jfxs/robot-framework
Standalone-chrome&firefox:
https://hub.docker.com/r/selenium/standalone-chrome
https://hub.docker.com/r/selenium/standalone-firefox
Before pushing the project to GitLab, we used a makefile to run the tests locally.
In this way, we tried the tests and the capabilities of the automation project in the local environment before working on GitLab.
Makefile example;
Many ways exist to parallelize test jobs:
- In general, tests that don’t change data (read-only tests) can be split with tags by using include and exclude arguments and run in parallel.
- The same tests with different contexts can also run in parallel by setting variables in the command line. Example: chrome/firefox
Pipeline architecture
In this way, our project starts to run tests simultaneously in chrome and firefox after each commit push and presents the report & log & screenshots in GitLab artifacts after the run.
Likewise, we can now include this automation project in the pipeline of other backend projects linked to this project.
Now we need to include the test automation project in the pipeline of the project it will test (coupon seller center UI). In this way, when a developer in the team makes a change in the coupon seller center UI project and makes deployment, this change in the stage environment, the interface test automation project will be triggered automatically and will present the test reports. If the tests do not pass after this change, production deployment will not be allowed.
Report publication
Once tests are run, there are as many reports as test jobs. The command rebot can concatenate all intermediate outputs in one final report. To avoid a non-zero return code the option --nostatusrc should be used.
Selenium tests
Some SaaS solutions are available like Sauce Labs or BrowserStack to test Web UI with Selenium. But headless Chrome and Firefox tests can be directly run with a Docker container declared as a GitLab-ci service. The host alias for the service is the Docker image named with a double underscore replacing the slash character.
Conclusion
We showed the technologies we use and how we implement them. We experienced one of these technologies Robot framework in our UI project. We continue to improve our current architecture.
We have more than 20 microservices in Coupon Domain. We are trying to apply DDD strategic and tactical patterns to our domain all the time. We are developing ubiquitous language to communicate with our stakeholders. We are organizing Event Storming meetings for architectural review and new features. We decide as a team on architecture and technology decisions and we are organizing analysis meetings. Join us to develop millions of coupons and high throughput applications. We have a lot of challenges 🚀
Resources
A Robot Framework and GitLab-ci pipeline example: https://gitlab.com/barisekici/gitlab-ci-ui-test
A lightweight Robot Framework Docker image automatically updated with GitLab CI and tested with Robot Framework: https://hub.docker.com/r/jfxs/robot-framework
