Bug-free, faster, and reliable App release to market is key to success for any startup. This problem becomes more complicated in the microservices architecture. As WinZO our teams are committed to enhancing user experience and giving them a smooth experience on the App so in this blog, we will go deeper into how our automation framework plays a vital role there.

Backend Test Automation is one of the important problems to solve in any Tech industry. With Backend automation in place, it is easy to recognize the contract changes or any other changes which can impact directly the application.

What were our criteria for the selection of Backend Automation?

Before picking up any framework from the market randomly, we thought of making a process through which we will be selecting the framework which will be best suited to our requirements.

Criteria for the selection of the framework were:

1. Low code

We want this framework with low coding so that anyone can contribute to the framework and no special training is required for a person to ramp up on this framework.

2. Solves most Backend cases

We not only have HTTP calls that need to be automated in, but also sockets and graphQL API which need to be automated. We want to have our framework in accordance with which can accommodate all of these calls without any additional plugins to be integrated with.

3. Suitability for team

WinZO Tech team is not limited/specified to one language, and we have used multiple languages across teams as per the need of the hour so our framework should be powerful enough to cater to all those needs.

4. Easy Implementation/Integration with Build tools

The framework should have easy integration with Build tools so that if we want to integrate the test run on every commit to master on the repository, it triggers the automation with some integration of webhooks.

5. Reporting and Maintenance

The framework should have good reporting which can be read through by anyone. Also, It should need Low maintenance.

6. Future scope of improvements

The framework should have a scope for improvement in the future.

Along with all the above criteria, basic things like parallel running, extended reporting, etc were also on the top of our minds during framework selection.

How we shortlisted Framework for POCs?

We researched for frameworks that can be fitted into the above criteria and shortlisted 3 frameworks:

1. Rest-assured with Java
2. Karate DSL
3. Mocha

Conclusion Of POCs:

We took up one simple and one edge case that can be automated and started on POC with the above frameworks. We lined up a few parameters which will declare the winner by itself.

• All the above ratings are on a scale of 1 to 10.

So with the above results, we were able to conclude that Karate DSL is best suited for our needs and solves most of the problems we can have for Backend Automation.

Karate Framework:

In this section, we will discuss one of the use cases we solved using Karate. We have used karate with the maven build tool.

Project Structure:

├── README.md
└── automation
    ├── pom.xml
    └── src
        └── test
            └── java
                ├── apiTests
                │   ├── platform
                │   │   ├── feature file
                │   ├── userService
                │   │   ├── feature file
                ├── requestJson
                │   └── userService
                │       ├── Json file
                ├── schemas
                │   └── userService
                │       ├── Schema file
                ├── karate-config.js
                ├── utilities
                │   ├── Common Utilities
                └── winzoTest.java

apiTests folder:

In the apiTests folder where all APIs are being kept. The feature file contains all the scenarios for the API.

Example for feature file:

@tags

Feature:

  Background: Loading the params, url and headers in background.

  Given url stag 
  And headers Content-Type = 'application/json'

  Scenario Outline:
  Given path ''
  When method HTTPMethod
  Then status <ValidateStatusCode>

  Examples:
  |ParamsToPass |
  |             |

If there is more than one scenario, we can pass on the data from examples, and a Scenario outline is being used but if there is only a single hit that needs to be made, it can be done using a Scenario without an example.

requestJson folder:

In requestJson where all the request body is kept in JSON. These JSON could contain variables as well in case needed to be passed from the scenario outline or from the feature file.

{
  "key1": "value1",
  "key2": "value2",
  "key3": "#(variable)"
}

Schema folder:

The schema folder is the one where all the response schemas are kept, which helps maintain the API contracts intact. Any online converter could be used for converting the response JSON to JSON Schema.

Config folder:

The Config folder is named Karate-config where all the common variables like URLs etc could be kept in. The main advantage of using this is, it could be configured on the basis of the environment level.

Utility folder:

The utility folder contains common utilities used across feature files for different operations. We have utilities for schema validation, connecting to DBs for data validation, random number/alphaNumeric generator, header management, and much more. You can write utilities in Java, and NodeJS which could be used in the feature files. Sample code for schema validation utility:

public class schemaValidate {

        private static final Logger logger = LoggerFactory.getLogger(schemaValidate.class);

        public static boolean isValid(String json, String schema) throws Exception {
            JsonNode schemaNode = JsonLoader.fromString(schema);
            JsonSchemaFactory factory = JsonSchemaFactory.byDefault();
            JsonSchema jsonSchema = factory.getJsonSchema(schemaNode);
            JsonNode jsonNode = JsonLoader.fromString(json);
            ProcessingReport report = jsonSchema.validate(jsonNode);
            logger.debug("report: {}", report);
            return report.isSuccess();
        }

}        private static final Logger logger = LoggerFactory.getLogger(schemaValidate.class);

Runner

Last but not least is our runner which is needed for running the test. The runner is named winzoTest.java. The main functionality of the runner is to run the test under a certain path, generate Junit and cucumber reports, and run the test in parallel.

@Test
    public void testParallel() {
        Results results = Runner.path("classpath:apiTests")
                .outputJunitXml(true)
                .outputCucumberJson(true)
                .parallel(1);
        generateReport(results.getReportDir());
        assertEquals(0, results.getFailCount(), results.getErrorMessages());
    }

    public static void generateReport(String karateOutputPath) {
        Collection<File> jsonFiles = FileUtils.listFiles(new File(karateOutputPath), new String[] {"json"}, true);
        List<String> jsonPaths = new ArrayList(jsonFiles.size());
        jsonFiles.forEach(file -> jsonPaths.add(file.getAbsolutePath()));
        Configuration config = new Configuration(new File("target"), "automation");
        ReportBuilder reportBuilder = new ReportBuilder(jsonPaths, config);
        reportBuilder.generateReports();
    }

So this is the overall structure of our Karate framework. This structure could be modified based on the need and it has flexibility in terms of usage.

We will go more deep down into the Karate framework in Part 2 of this series where we will discuss different types of DB connections and data passing between different APIs for end-to-end flow and much more. Stay Tuned…

As India’s Largest Interactive Entertainment Company, Winzo envisions establishing India as the next Gaming Superpower of the world, fuelled by revolutionary innovations and path-breaking engineering. Resonate with our vision? Visit our Careers page (https://winzogames.hire.trakstar.com/.) and reserve a seat on our Rocketship.