Karate: 5 reasons why you should try it
In the previous article, we described the main features of Karate and some practical examples on how to use it to write automatic tests for REST and GraphQL API.
Let’s now analyse some of the advantages of choosing this test framework and point out the differences with REST Assured.
Main advantages over REST Assured
- No compilation needed: Karate test scripts are written as .feature files:
The equivalent in REST Assured is a test class written in Java:
- Data Driven Tests: Karate provides this feature natively in two ways:
- ScenarioOutlines and Examples table:
This should be familiar to people who have experience with Cucumber.
- call and JSON Arrays:
data-driven-example.feature
create-characters.feature
In data-driven-example.feature there’s a JSON array (table) named characters with name, age, house and birthday (from my beloved Harry Potter saga). In line 8, the call keyword is used to invoke create-characters.feature passing the array characters as an argument. As a result, the scenario in create-characters.feature will be invoked three times (one for each item of the array).
From line 9 to 12 the use of equal match (match == ) and embedded expressions (‘#(name)’) allows to easily check the data in the response are correct. REST Assured does not provide a native way to perform parametric tests so typically you would use external libraries like JUnit or TestNG for the same goal:
The example uses the DataProvider of TestNG. It is quite easy to read and understand, however, Karate is “light” when it comes to defining the post body: indeed in this example, I had to deal with String (requestBody) and fight with escaping, while native JSON support is provided within Karate (as described here)
- Native environment switching: Karate provides an easy way to configure different environments for tests and more, in general, to configure system properties by using the karate-config.js file:
karate-config.js example
This configuration allows us to launch tests in different environments by simply passing karate.env as a parameter:
All the variables defined inside config are global, so, for instance, someBaseUrl can be used as a URL in feature files. With REST Assured there isn’t direct support for environment switching, and typically this is done by configuring specific maven profiles in pom.xml which allows running tests in different environments.
- Match full payload in one step: given a nested JSON in Karate is possible to match the full payload in one time, as shown below:
The same check in REST Assured needs more lines of code: this is because we can’t compare JSON in one line but we have to compare primitive objects one by one: in order to check that actual is equal to expected, we need to make assertion respectively on name, age, and nationality and this can become quite complex when JSON is deeply nested (as an example please refer to the project at the end of the article).
Update JSON payload/object: in Karate it is possible to manipulate JSON objects, for instance, set the value of a field using the “set” keyword, or remove by using the “remove” keyword:
Set example
Remove example
It is not possible to modify a JSON object in REST Assured.
A practical code example
To better understand the difference between Karate and REST Assured also have a look at this project where the author of Karate, Peter Thomas rewrote the tests in Karate. The difference in the number of code lines is impressive: 431 against 67!
Conclusion
I still haven’t found the perfect tool for test automation (and maybe it doesn’t exist). I think testers have to try different tools to find which one is the most suitable each time depending on the needs. Try Karate, I think it’s worth it.
Happy testing! (and please do not hesitate to leave a comment)
