I’ve recently talked about a testing framework called Cypress. In this article I will talk about another one: a pretty simple testing framework for REST API Automation called Karate. In order to best describe it, here’s a pretty descriptive excerpt from the official source:
Karate Framework is the only open-source tool to combine API test-automation, mocks and performance-testing into a single, unified framework. The BDD syntax popularized by Cucumber is language-neutral, and easy for even non-programmers. Besides powerful JSON & XML assertions, you can run tests in parallel for speed – which is critical for HTTP API testing.
First, let’s compare Karate test with Cucumber and REST-Assured.
Cucumber: + we must implement steps and POJO:
For pre-conditions use, Karate proposes to use another feature files:
Since Karate is written in Java, it has java integration.
Calling Java method from API test, e.x generate uniqueId:
Another advantage of using Karate is its assertion capabilities:
Schema validation. User friendly formating of response validation. Reusing json as a variable. Karate markers. DDT. Similar to Cucumber, but compared to Cucumber, where variables are static in the table, in Karate we can import a csv file with data. Can be user e.x. in boundary testing of api endpoint.
Parallel execution. Running with Junit5. In the example we run all tests/feature files with tag @regression.
Reporting. Allure, Cucumber report. From the box Karate propose the report like next one:
But also we can easily integrate Cucumber report or also Allure 😉
In case of Cucumber Report we can obtain something like:
Some other cool features of Karate Framework: Json Path, UI step-to-step debug, Integration with CI, Build-in ENV switcher, etc.
Summary: Pros and Cons of using Karate Framework:
|Integration with java, JS||No ‘find usage’, auto renaming|
|Json, xml native support||TestNG support deprecated|
|Powerful assertion capabilities||Has no Auth Schemes out of the box|
|No programming skills required|
Miguel Angel Apolayo Mendoza
How to pass an access token that answered the first service and use it in the header of the second service and use the access token that answered the second service in the header of the third service and the same with the fourth, fifth …