Karate

 Karate tool that has been developed by Peter Thomas, one of the great tools that come to the rescue of API testers.

Karate framework follows the Cucumber style of writing the program which follows the BDD approach. The syntax is easy to understand by non-programmers.

It provides the users with the ability to execute the test cases in Parallel and perform the JSON & XML checks.

certain key points can be deduced to further understand the Karate tool in detail:

• Karate is a BDD testing framework instead of a TDD.

• It is designed to be easy for non-programmers. This feature is a game-changer as it allows for more use and access by many people regardless of their technical background or capacity.

• It makes use of the Cucumber feature file and the Gherkins language to write the test which is very easy to understand.

All of these features make it one of the most favorable automation tools available today.

History Of Karate Framework

Created by ‘Peter Thomas’ in 2017, written in Java 

it uses Gherkins files, which is a result of its relationship with the Cucumber framework.

The automation software is an extension of Cucumber, therefore inherits the use of Gherkins file in its operation. The big difference between the two is that Karate makes no use of Java while testing, but Cucumber does.

The following are some features of the Karate Testing Framework:

• Makes use of easy-to-understand Gherkins language.

• It requires no technical programming knowledge like Java.

• It is based on the popular Cucumber standards.

• Easy to create a framework.

• Parallel testing is the core functionality that is provided by the Karate itself, hence we need not depend on Maven, Gradle, etc.

• UI for debugging the Test.

• Calling a feature file from another file.

• Provides supports for the Data Driver Testing that is built in-house, hence no need to depend on external frameworks.

• Built-in Native Rest Reports. Plus, it can be integrated with the Cucumber for better UI Reports and more clarity.

• Provides in-house support for switching configuration across different testing environments (QA, Stage, Prod, Pre-Prod).

• Seamless support for CI/CD integration that can be useful.

• Capable of handling various HTTP calls:

  • Web Socket support

  • SOAP request

  • HTTP

  • Browser cookie handling

  • HTTPS

  • HTML-form data

  • XML request

The following table enlists a few more prominent differences between Rest-Assured & Karate Framework:

S.No	Basis	Karate Framework	REST-Assured
1	Language	It uses a combination of Cucumber and Gherkins	It makes use of Java Language
2	Code Size	Usually, the line of code is less, since it follows Cucumber-like structure	Line of code is more since it involves the usage of Java language
3	Technical Knowledge required	Non- Programmers can easily write the Gherkins code	Technical knowledge is required to write Java code
4	Data-Driven Testing	Need to make use of TestNG or equivalent to support the same	In-house tags can be used to support data testing
5	Does it provide SOAP call support	Yes, it does provide	It is only related to a REST request
6	Parallel Testing	Yes, parallel testing is easily supported with the parallel report generation too	Not to a large extent. Though people have tried doing this, the failure rate is more than the success rate
7	Reporting	It provides in-house reporting, hence doesn’t need to be dependent on external plugins. We can even integrate it with Cucumber reporting plugin for better UI.	Need to be dependent on External Plugins like Junit, TestNG
8	CSV support for external Data	Yes, from Karate 0.9.0	No, have to use Java Code or library
9	Web UI Automation	Yes, from Karate 0.9.5 Web-UI Automation is possible	No, it’s not supported
10	Sample GET	Given param val1 = ‘name1’ And param val2 = ‘name2’ And path ‘somelocation’ When method get Then match response contains ‘OKAY’	given(). param("val1", "name1"). param("val2", "name2"). when(). get("/some\location"). then(). body(containsString("OKAY"));

Structure Of Karate Test Script

A Karate test script is known for the possession of the “.feature” extension. This property is inherited from Cucumber. The organization of files in Java convention is also equally permitted. You are free to organize your files according to the Java package conventions.

As per the creators of the Karate Framework, they strongly believe that we keep both Java and non-Java files side by side. As per them, it is much easier to look out for the *.java and *.feature files when they are kept together, rather than following the standard Maven structure.

This can be easily done by tweaking your pom.xml as follows (For Maven):

<build>        <testResources>             <testResource>                    <directory>src/test/java</directory>                    <excludes>                             <exclude>**/*.java</exclude>                     </excludes>              </testResource>         </testResources>          <plugins>         ...         </plugins> </build>

Following is the outline of the general structure of Karate Framework:

Now, since this Karate Framework is using the Runner file, which also is needed in Cucumber to run the feature files, so most of the writing will follow the Cucumber standards.

Let us try to understand the components of the feature file:

• Feature: Keyword explains the name of the feature we are testing.

• Background: This is an optional section that is treated as a Pre-requisite section. This can be used to define what all is needed to test the API. It contains HEADER, URL & PARAM options.

• Scenario: Every feature file that you will see will have at least one feature (although it can give multiple scenarios). It is the description of the test case.

• Given: It is the step that needs to be executed before any other test step is performed. It is a mandatory action to be performed.

• When: It specifies the condition that should be met to perform the next test step.

• Then: It tells us that what should happen in case the condition mentioned in the When is satisfied.

Note: All the above-mentioned keywords are from the Gherkins language. These are the standard way of writing the test scripts using Cucumber.