This blog is about how to develop automated test cases for SAP Commerce storefront using a generic automation framework. The whole framework was built from scratch to demonstrate the flexibility of the framework, all the design patterns, test cases, and their implementation are shared below.
At the moment there are no publicly available examples of automated test practices for SAP Commerce. After deploying SAP Commerce developers/testers have to test them manually to check the health of the build, that is not how we do things at FAIR, we advocate incorporating best practices.
These automated test cases of the storefront can be configured into any CI/CD pipeline. Whenever SAP Commerce will be deployed these automated test cases will be executed within the same build and will give us the status of the build at the end.
- SAP Commerce (B2C/B2B Storefront Accelerator)
- The IntelliJ idea
- Selenium Web Driver
- Cucumber (Software tool that supports BDD framework)
- The one-page object model for design pattern
The functionality required when building a framework following best practices
Write your test cases English in a Feature file, unlike other automation frameworks, Cucumber tool allows you to create your test cases in plain English text which means non-technical resources e.g. BA, PO, stakeholders can create or go through the test cases and find the loopholes or missing scenarios in the test case. It also serves as the documentation part of your project.
Maven is used to adding the dependencies in the POM.xml file to configure/download the files within the project and to run the automated test cases using maven commands. Maven will help us package and execute the automated test cases in CI/CD pipelines.
Tags are the functionality that Cucumber comes with, it helps you to execute specific test cases with the help of the tags.
For example, there are many automated test cases for storefront and out of those you want to execute only product listing test cases as part of a smoke test so to achieve this you can add tag “@product-listing” at the start of the test case that you want to run as part of sanity check.
One-page object design pattern can be used for the implementation of automated test cases. The code can be distributed in such a way that the implementation of the methods can be created in a separate folder to make it more dynamic and those methods than can be used in different test cases.
Reports can be generated after running all the test cases which will mention how many test cases were passed and failed. For the failed test cases it will provide the stack trace as well mentioning the reason for the failure of the test case.
Screenshot functionality is available for the failed test cases. Whenever any test case fails it will take a screenshot and will embed it to reports for the failed test case. So, with stack trace, the screenshot will be also available of that step where test cases failed.
Firefox and Chrome browsers will be leveraged and many other browsers can be configured within this framework to perform the cross-browser testing.
How to implement best practices
Test cases will be created using Gherkin format, to create a test case add a feature file in the feature package and add the scenario using Given, When, Then format. You can also add tag above the test case to run multiple test cases at a time.
An example of a feature file can be seen above.
Step definition has all the scenarios implementation created in the feature file shown below.
The page object model is a design pattern which is created for a separate method implementation shown below so that the same method can be used in multiple scenarios and it will be easy to maintain if any changes are required.
Execute test cases: mvn clean mvn test -Dcucumber.options="--tags @SAP" -Dbrowser=chrome -Denv=storefront
These automated test cases can be executed as part of the deployment of SAP Commerce. Such a framework would be very flexible and could work for the OOTB storefront or custom storefront. When deploying enterprise applications ignoring proper testing or doing manual sanity checks would undoubtedly take you down the rabbit hole you don’t want yourself to be in.
Ensuring best practices when creating automated test framework is paramount when working with enterprise applications, it provides confidence to the developers as well as the stakeholders.