API Testing using Karate Framework

20 May 2021

It stands for Application Programming Interface. API is a software intermediary through which communication between applications is done.We send requests to API and it will provide us the response.

Types of API Requests

• GET: It is needed to get any data from API.
• PUT/ POST: It is needed to send data to API to create/update resources.
• DELETE:  It is needed to remove specified resources.

Typical API request

• API URL: HTTPS link to API. It is usually called end-point.
• Headers: Usually its Content-Type or Authorization Token.
• Method: GET, POST, PUT, DELETE
• Body: It is a JSON object with requested data. For GET and DELETE we don’t need a body.

HTTP response status codes

• 2XX (200, 201,…): Request was successful and API was able to process requests successfully.
• 3XX (300, 301,…): API returns redirect URL.
• 4XX (400, 401,…): It means something was wrong with the request. It is a client error.
• 5XX (500, 501,…): API accepted the request, but for some reason was not able to process the request. It is a server error.

Need of API Testing

• It takes less time than UI automation. In it results are published faster, so you no longer have to wait to see if the API is working correctly.
• As the API testing takes less time, so the deployment of the respective APIs also becomes faster which results in quick turnaround time.
• Detecting failures early, even before the application’s user interface is created.

Karate Framework

The structure of karate follows the writing style of the cucumber program. The Syntax of it is easily understandable even for non-programmers. Karate framework is the only API testing tool that has combined API automation and performance testing into a single tool.

Pros and Cons of Karate Framework:

• Pros:
• • Easy to start with little coding.
  • Native JSON support: We can write JSON expressions right in our feature files.
  • It has a very powerful JSON validation.
  • In Karate we can write our code in java or JS.
  • Karate has multi-thread parallel execution.
  • It has detailed reporting & logs.
  • Performance testing can be done by integrating Gatling framework.
• Cons:
• • It uses its own scripting language.
  • No intellisense support in IDE.
  • Difficult to find mistakes in code.

Development Environment:

• It requires following installation:
  • Java 8 or higher,
  • Maven
  • Git
  • Yarn
  • Postman
  • Visual Studio Code
  • VS code plugins:
    • Cucumber,
    • Karate runner
    • Java Extension pack

Karate Structure:

• pom.xml: It is a file where we manage all our dependencies and plugins to run our applications.
• java folder: It is where karate projects are located. It has following:
• example folder:
  • TestFile.java: It is a Karate junit5 runner, The “Runner” class is most of the time named TestFile.java or TestRunner.java.
  • Users.featurefile: It contains all the testing scenarios that are needed to be tested to make sure that the API is working as per the expected requirements.The feature file should be in the same folder in which runner is present. Feature file is where we write our test. Feature file has scenario and each scenario is the test.
• logback-test.xml: where we configure our logging and how we want to see print of our log in console.
• karate-config.js: It is the main file where the execution starts. We can setup ‘global’ variables using some simple JavaScript. It is used to execute any code before running any test.

Components for writing test in feature file:

• Feature: This is a keyword which is written at top of the feature file and it describes what is being tested briefly.
• Background: This is an optional section which consists of the pre-requisites. It may contain all the things which are needed to test the API. The variables which will be defined under the background section will be ‘global’ to all scenarios and re-initialized before execution of each scenario. For example, we can define Url in starting just after ‘Feature’ line, and then this Url will be used in a complete feature file for each scenario.
• Scenario: Scenario is nothing but the Test Description.
• Given: This is the step which is performed before any other step in the scenario. It is a mandatory action to be performed.
• When: It defines the condition that is expected to perform the next step of the test.
• Then: It defines what should happen if the when condition is true.

Basic Example of writing test in feature file:

Feature: #Description

Scenario: #Test Description

Given url 'HTTP request url'

When method 'Method_name'

Then status 'status_code'

Scenario: #Test Description of 2nd scenario

Given url 'HTTP request url'

When method 'Method_name'

Then status 'status_code'

Assertions:

• We can verify if our response is correct or not by using assertions. Few are the examples of assertions:
  • match == : The double equals sign does the comparison.
  • match contains: It is used to check if some key exist in response JSON.
  • match !contains: It is used to check if a key-value-pair does not exist.
  • Fuzzy Matching: It is basically assertion of our response type with response body
  • Schema validation: It is used to verify contract between Frontend and Back end.