Karate API Testing

Santiago Cardona Giraldo
blog-img

API Testing might be one of the most common skills that all testers should have; the idea is to test our backend systems, especially when “modern” architectures are being designed and developed in microservices and legacy systems are migrating to microservices and micro frontend systems.

Usually, when we talk about backend testing, specifically API testing, we can find many ways to implement this testing process, and almost all options incorporate a manual approach. The APIs can have different developed methods (get, post, delete, etc.) that we have to verify. For example, we test the request we are generating to our backend, test the response, and compare if the information is correct regarding what we are expecting.

This article aims to find another option to test the backend by using Karate and gets the best benefit from this tool when we want to implement an API automated testing approach.

Perhaps, you might ask yourself, Why should we use Karate? Of course, the answer depends on the context of the application, the technology, the architecture, etc. However, suppose you are interested in automating the same tests you are doing every day; in that case, you first need to verify your test environment for all APIs (smoke testing), or if you have continuous releases which require to validate the environments and check first every API response, the suggestion is you should test those scenarios automatically; Karate can be an excellent choice to handle it, and I can mention many, and many more cases where we can use Karate, but the most crucial aspect to remark is that Karate is really easy to configure and is very friendly to use, especially if as a tester we don’t have a lot of programming skills.

The API test cases are very specific, and they are usually implemented to interact with the request and response; developers and QAs test them only where and when it is necessary, but almost no one has the good practice to implement automated continuous testing to cover that necessity; as we know an API can frequently change for different reasons, and sometimes we are not aware of those changes because we are not notified on time about those changes, and it can be time-consuming if we have to check each API manually every moment the APIs get changes. Karate offers us an easy way to resolve it, and if you have the possibility to integrate it with pipelines, it will be much better.

So, welcome to this article; let’s get started!

Karate is an open-source framework created by Peter Thomas in 2017. This tool has many testing capabilities; they all have a different purpose and could be used depending on what you are looking to automate, but in my experience, I think, Karate might be more beneficial for API Testing (HTTP / WebSocket Client).

img

Karate API Testing has the possibility to be integrated with Gherkin and cucumber, frameworks commonly used for automation testing. Even though Karate offers many testing capabilities, the focus of this article will be on API Testing (HTTP / WebSocket Client).

Before starting with API backend testing by using Karate, we need to configure our environment, tools and dependencies. To achieve it, we need to follow these steps:

    1. Configure local environment variables and their paths (JDK (Recommended Java 8) and Maven or Gradle (It depends on your preference)
    2. Create a Java project with some management dependencies (mentioned in 1)
    3. In my case, I use maven, so I need to configure the pom.xml
    4. Download the following dependency from https://mvnrepository.com/

* Karate-core — Let’s use the stable version, not the RC (release candidate); The following example:

com.intuit.karate karate-core 1.1.0 com.intuit.karate karate-junit5 1.1.0

    1. Create into the project src/test/features each file.feature that you will test depending on your test scope
    2. Start creating the test scripts:

API testing is associated with testing different methods developed for each API (GET, POST, DELETE, etc.), the request, response, codes and others. So, by integrating gherkin + cucumber, we can start testing each one of them.

img

a. GET

In this case, we use the method GET and do the assert through them; if the status is different to 200, the test case will fail.

img

In this image, you can see that I am making multiple assertions (status, response, response data length, id, last name). It will be a good option, especially when our APIs have several business test cases.

b. POST

In this test case, I add a background that I will use in different scenarios. First, I set up the URL (where the API is), and the header needs to send the data and the expected output. The header and response are located in another folder in the project called “data.”

If we want to implement other methods, it is enough to change the method name and the assertions associated with the business cases.

7. Generate the report

To end this article; I will talk about reports. It’s one of the aspects that I like most about Karate because it is swift, intuitive, and provides detailed information. For example, when I run about 15 test cases, the execution takes less than 7 sec; of course, this time depends on the API, data, and environment, but If you consider that It is taking too much time, you can implement it by using parallel tests

You can click on GET Method, and you can find more details, step by step, for each feature, getting the response information, checking the assertions, etc:

In conclusion, Karate could be an interesting option to automate back-end API testing, specifically in projects where it is necessary to execute several test cases recurrently. Also, Karate could help solve or improve the time to market, timeliness, quality, technical proficiency, and implement continuous end to end testing with the automation approach.

¡Enjoy Karate!

References: https://github.com/karatelabs/karate https://cucumber.io/ https://github.com/cucumber/cucumber/tree/master/gherkin https://automationstepbystep.com/ — Special thanks to owner/creator of this course: Raghav Pal