Testing APIs with JetBrains HTTP Client
Let's dive into the world of API testing tools again (here's previous part). Today I will focus on the JetBrains HTTP Client. Let's see how HTTP Client fits into the API testing landscape and how to use it.
Where does HTTP Client fit
There are two main approaches to testing APIs, using:
- Dedicated API Testing tools ⚒️
- Common programming language
The first option, using dedicated API testing tools, is preferred by QA engineers. The advantage is that the test are outside the app code-base and can be maintained by QA engineers. Additionally, these tools offer a user-friendly UI, which makes it easy to create and maintain tests. QA people may create tests without coding, but for advanced scenarios some level of scripting is required. Examples of these tools are Postman, ReadyAPI or JMeter. They support various types of APIs, including REST, SOAP, GraphQL, gRPC, Kafka, etc. The tools offer Git integration, though hidden under cover of the UI (tool functions) and usually limited.
The second option is to use a programming language, preferably the same language as the API/Application is implemented in. For instance, if we use Python FastAPI to implement the backend app, we can use FastAPI client with pytest framework to run the tests. This option is mostly liked by developers. No other "unnecessary" tools required, everything in Git, no need to leave IDE. On the other hand the tests are delivered together with the code, changes merged into the code-base by developers. QA people without coding skills are out of the game. This is definitely fine for unit testing, but questionable for integration and other types of tests. Especially if the tests cover multiple APIs.
Where does HTTP Client fit here? Somewhere between. It simplifies creating the tests, you can easily call APIs without coding. On the other hand, the tests are text-based, and it's integrated into JetBrains IDE (IDEA, Pycharm or other). You can store the tests in Git without any limitations.
HTTP Client supports most of the functions we are familiar from Postman (environments, variables, etc.), actually HTTP Client usage is very similar to Postman (e.g., validating responses with Javascript). Besides REST, HTTP Client supports also GraphQL, WebSockets and gRPC.
The Basics of using HTTP Client
As shown in the picture bellow, all we need to start is to type HTTP method, URL and optionally the payload (depending on the method). Then we can hit the green arrow to run the request.
The response is shown in the bottom panel (see bellow). Something we are pretty familiar from the API testing tools. You can get the test on Gitlab. The examples here use BankGround API.
Even building a multipart request is pretty easy. GET request even easier, only needs the URL and we are ready. ✅
The Environments and Variables
We don't want to change the URL every time we switch between environments. We use environment variables in the scripts and then choose one of the environments to run the request. The environment variables are defined in the http-client.env.json file.
Example of the http-client.env.json file:
{
"qa": {
"name": "QA"
},
"prod": {
"name": "Production",
"base_url": "https://bankground.apimate.eu:443"
},
"dev": {
"name": "Local Development",
"base_url": "http://localhost:8004"
}
}
It's the public part, HTTP Client offers combining public part of the environment with the private part, http-client.private.env.json. The public and private part make together the environment configuration.
How to use variables? Once they are defined in environments (or else), we simply use {{variable_name}} in the tests.
During the test execution it's replaced by the actual value.
Scripting
The HTTP Client supports Javascript to do easy scripting. For each step we can set a:
- Pre-request script: to calculate parts of the request or do any other preparation.
- Response handler script: to validate the response or do any other post-processing, such as storing an access token to be used in the next requests.
In the pre-request script I have set up the username and password variables, since the username must be unique in BankGround API. The response handler ensures we get the expected HTTP status code and content type.
Running multiple steps
We can execute all test steps in the test file by pressing the green arrow in the top left corner. All steps are executed and the results are listed bellow. You can filter the results, check the responses or your validations.
Besides manual test execution, you can use the HTTP Client in pipeline with CLI.
Summary
We went through basic API testing functions and how to make them work in JetBrains HTTP Client. With the environments and scripting we are able to build advanced test scenarios and run them either manually in IDE, or in pipelines with CLI.
All the examples shown here are available in Gitlab. Download them into JetBrains IDE and try it yourself! 🚀🚀🚀