Spring Boot REST API Testing with Postman
Coding is just a small part of the software processes. You need to prove that your code is operating as expected. They will question your ability of coding by asking you to write some tests that challenge your API :)
In this post, we will concentrate on testing our code via Postman. If you are a bit close to the software development processes, you must have heard the Postman. Most of the use cases of the Postman is sending request to the API’s to gather information or create new data. Well, CRUD operations basically…
Let’s take a look at the less popular side of the Postman. But first, I want to mention about the API that we will test.
Spring Boot REST API
Before we start I want to share my Spring Boot API which is the lucky API that will be tested by us. You can find the github link here. Also you can use that API as boiler plate for your any-purpose Spring Boot app. Feel free to play around with it.
This is the project structure of the app:
Let me explain what I did on the Spring Boot side. Well I have an entity to store Customer information.
And customerType is just an enum such as:
I don’t want to dive into the code too much. Briefly, we will test 4 main services: Save Customer, Get Customer by Id, Get All Customers and Delete Customer by Id.
There are some validations to pass in order to get expected outcome. For example, to save, your notificationEmail should be unique together with the customerType. And you should not send the id parameter while creating customer because it must be generated by the API etc.
Each validation has their own exception to handle and error message to inform the client. If any error occurs, the API responds a data that consists of error message and time variable.
So you can get the code here and run the Spring Boot app to try the Postman tests.
Postman Intro
I hope the info is enough for you to understand that app.
Before we start the testing our magnificent API, I want to share my Postman collection here. You can directly import it to your workspace by using Import -> Link and paste the URL.
Before we begin let’s talk about some basic terms. If you are familiar with Postman, you can skip this section.
Pre-request Script: As you can guess, it is executed right before the request is sent. You can use that for many purposes such as getting and setting variables that may be used for the requests, sending login request to get token for authenticated API’s, etc. Since our app is simple we will only use it for setting collection variables to use in our request body.
Tests: Imagine that you sent the request, after you get the response the tests will be triggered. You can just simply use them for test purposes and additionally you can set some variables by using response. Because the test script is triggered after response gathered.
The Test Cases
Let’s begin with testing the save Customer service.
Case 1: Customer should be saved successfully when the inputs are valid
I created a pre-request script for that request.
I am too lazy to set an unique email for each save request, so the script creates a random string for my email prefix and sets it to a collection variable called randomEmailPrefix.
Then I can use that variable in my save request such as {{randomEmailPrefix}}
I am just sending the random email and customer type to save the customer
I defined some tests to check to certain parts of the response. The test:
If you read the tests, you can see that it is just a plain English. We are not crafting a magic here. That’s the beauty of the Postman. Let me mention about the basic parts.
We are defining the test methods with pm.test() and you can specify the title of the test and the function inside of it. You can add true-false statements to test and validate the response. In order to validate you can reach the response by using pm.response.
Since I am expecting a successful response here, I am validating the response status (200 means OK . You can check the HTTP Status codes for further information).
Sometimes pm.response is not enough and you need to format the response. Then you can use pm.expect(). The API should respond a non-null json data. When the customer is saved successfully, the id generated automatically. So the id should not be null:
There are many alternatives to validate the response. Such as you can validate the status as OK and the response has a json body by using pm.response:
After creating the customer, I want to store the customerId at the collection variables in order to use that at the later cases. It will be saved as createdCustomerId:
At this case, we just used a pre-request script to create email and store the variable. Plus we used the test to save customerId parameter to use it for further cases.
Case 2: Customer should not be saved when the notification email used before
POST request to the URL: /api/customer/
Sometimes we forget the email we used while creating profiles and try to re-use it. In that case the API should warn us and the response should give details about the mistake we made.
Let’s send the same request with the exact email address. (Remember we did not re-create the random email here. We are still using the same mail created at the Case 1)
The API should tell me that my request is inappropriate (BAD REQUEST status: 400). Plus, the error message should not be null and it may tell me that “Notification email has already used with the customer type”:
Next we will continue with the Get Customer by Id service that returns individual customer info.
Case 3: Get Customer by Id service should return an accurate value
The GET request to the URL: /api/customer/{{createdCustomerId}}/
I am testing the get the info of the customer which is created at the Case 1. Since the customerId is saved at the collection variables, we can get the customer Id by pm.collectionVariables.get(“createdCustomerId”).
The expectation is to get an OK response. Additionally, the accuracy of the data data can be validated by checking whether the the id of the response customer is equal to createdCustomerId or not:
Case 4: Get Customer by Id service should fail when Id is not valid
The GET request to the URL: /api/customer/-1/
Sometimes the client feels lucky and tries random numbers to get customer info. Then the API needs to warn them gently and told that the request is bad (STATUS 400) and the error message should not be null:
Case 5: Get All Customers service should return customers successfully
The GET request to the URL: /api/customer/
As you remember, I have created a customer during the first test case. So if I call the getAllCustomers service, I should get a response OK and the customers list size should be greater than zero:
Case 6: Delete Customer by Id service should delete the customer
The DELETE request to the URL: /api/customer/{{createdCustomerId}}/
I am using the same customer that created at the Case 1.
The API should delete the customer and respond OK:
Case 7: Delete Customer by Id service should fail when Id is not valid
Since at the previous step I deleted the customer, if I re-send the same DELETE request, I should get an error.
Sending the DELETE request to the URL: /api/customer/{{createdCustomerId}}/
Now I am waiting for a 404 (NOT FOUND) error and the error message must not be null:
Final Words
Again, if you don’t want to get to copy and paste the examples, you can find it here to import by using Import -> Link.
When you imported it you can run all of the tests by right clicking the collection and choose “Run collection”. If the Spring Boot app is running you will see something like this:
As a further study, Postman tests can be integrated to CI/CD processes as a stage to validate the functionality of the services. I might write another post about that too.
I tried to explain basics of the Postman API testing here. I hope you enjoyed it.
Cheers
