Karate? Isn't that that Japanese martial art? Yes! But Karate is also an extremely popular test framework among the IT community. In our projects, we often have to deal with large monolithic software structures that we migrate to a modern cloud environment with microservices. Our quality assurance team has put various test frameworks through their paces in different use cases and was admittedly a little surprised themselves by what Karate is capable of.

In complex software projects with a monolithic structure and increasing numbers of users, it may become necessary at some point to break up this monolith and separate out the individual specialist domains. This is precisely where Karate helps us to ensure a smooth separation of the individual areas into functioning microservices. But what exactly is this Karate?

What is Karate?

As already mentioned, it is a testing framework. Karate was developed specifically for API and web service automation and offers a simple yet powerful solution to build automated tests for web applications. Above all, the ability to write tests in a clearly understandable, natural language, which allows non-developers to be involved in the testing process, makes Karate the tool of choice for many.

Launched in 2017 by Peter Thomas, the open-source variant quickly generated hype around itself that continues to this day. In one framework, the application combines: API test automation, API mocking, UI test automation (mix between UI and API tests possible) and performance testing. The tests are written in the language-neutral Gherkin, which also means that they are easy to understand and clearly structured. This also has advantages for developers, as cognitive load is significantly reduced and these resources can be used elsewhere.

Behaviour-driven development

The Gherkin syntax has its origins in Behaviour-driven development (BDD). This is a method in agile software development that describes and tests the behaviour of a system from the user's point of view. The core of the method is the early involvement of all those involved in the project, such as developers, testers, experts and stakeholders, in order to establish a common language and a common understanding. BDD strengthens the cooperation between quality management and business analysis.

In the BDD, test cases are defined together, which are called scenarios. These scenarios describe the desired behaviour of the software. To test this behaviour, mock objects are built that simulate the actual behaviour of the software. Tests are then developed against these mock objects and gradually replaced by the actual software logic until the software is finalised. This basic idea forms the foundation of the BDD approach.

Karate integrates these BDD principles, among others, and thus offers an easily readable, Gherkin-based syntax to describe test scenarios in natural language. This allows developers, business analysts or project management to participate in the test description and precisely define the behaviour of the system. But what exactly do these karate tests look like and what is it that makes them so attractive?

API & UI Testing

Karate offers powerful functions for API testing as well as testing UI components.

For API testing, Karate allows sending HTTP requests as well as checking responses. It also supports testing at different levels (XML, JSON, etc.), including interaction with databases and external services, to perform comprehensive API tests and check the behaviour of interfaces in different scenarios.

Our experts have developed a small example of an API test in which two scenarios are tested. In the first scenario, the GET request for the user details with the ID 123 is sent and it is checked whether the status code 200 is returned and the expected user response matches. In the second scenario, the POST request to create a user is sent and it is checked whether the status code 201 is returned and the created user response contains a numeric ID.

API Test

API

This example is also an excellent way to show the influences and advantages of BBD in Karate. The terms given, when, then and and come from the Gherkin syntax and give a rough idea of what this test is about, even without being familiar with Karate. Given stands for the precondition, when for the action that will be performed and then for the expected reaction of the system. And can be used in conjunction with other keywords to complete them.

For UI testing, Karate offers user interface (GUI) interaction through web browser simulation. Developers can build test scenarios that include, for example, filling in forms, clicking buttons and checking the information displayed. The use of selectors makes it possible to identify and validate UI elements.

Our Xperts have also come up with an example for a UI test. Here, a website is opened, the login form is filled in and the login button is clicked. Then it is checked whether a welcome message is displayed.

Login

Feature: Login

Scenario: Verify Login Functionality
    Given url 'https://example.com'
    When driver '#loginForm input[name=username]' = 'testuser'
    And driver '#loginForm input[name=password]' = 'password123'
    And driver '#loginForm button[type=submit]' click
    Then driver '#welcomeMessage' contains 'Welcome, testuser'

UI Test

A major advantage of Karate is that it seamlessly integrates API and UI testing. Developers can create test cases that cover both API and GUI behaviour. This enables comprehensive testing and prediction of the end-to-end behaviour of a system. Using Karate for API and UI testing offers many benefits such as improved test coverage, consistent syntax across test types and easy maintenance of tests over time. Karate also enables the creation of comprehensive test reports and accurate analysis of test results. Overall, Karate is a powerful solution for API and UI testing that helps developers deliver high-quality software with high reliability.

How do we work?

As a software service provider, we repeatedly work with clients whose software landscape consists of a complex monolith that has grown over the years. While such a structure initially seems to be easier and cheaper to realise, the challenges for trouble-free operation grow with the size of this structure. In order to be able to guarantee a functional system with rapidly increasing user numbers and features, a cloud migration with microservices is often unavoidable. As already mentioned at the beginning, Karate supports us here in separating the individual specialist domains and transferring them into separate microservices.

However, before we separate a domain from the monolith, we have to make sure that it works separately from the monolith. To do this, we write tests in Karate for the respective subject domain, and if these tests deliver a positive result, we separate the domain out of the monolith and migrate it to a microservice. We then run the tests against the microservice as well. If the tests deliver a positive result here as well, we can be sure that everything is working smoothly. This means that all clients that previously used the monolith can be transferred to the microservice without any problems.

In addition to the advantages of decoupling the individual specialist domains and the enormous scalability, a cloud migration with microservices can also compensate for many other serious disadvantages of a monolithic software structure. Nevertheless, it should always be carefully considered whether a migration is worth the initially higher costs. Basically, the larger the monolith, the more likely it is to be worth it. So if you decide to migrate to the cloud, it is all the more important that it is implemented smoothly and that you end up with functioning microservices.

With its testing possibilities, Karate provides an almost perfect setup for this - but its use is by no means limited to cloud migrations. Due to its nature (Gherkin syntax, all-in-one solution, etc.) and its many integration options at different levels (e.g. XML, XPATH, JSON), Karate has established itself as the standard in many areas when it comes to fast and reliable testing.