Testing with rest-assured in 10 minutes
Testing is something that involves many activities, and one of these activities is testing APIs. Many tools and frameworks help increase the API test coverage, and one of the frameworks is Rest-assured.
If you are also curious to know other tools to test APIs, check these links:
Which tools are we going to use here?
The following are the IDE and tools used, but there is no need for changing your tools to follow this tutorial:
- IntelliJ IDEA
I am assuming that you have a designated API ready and running. We will use the API implemented in this tutorial: https://amanajas.medium.com/create-a-rest-api-with-flask-in-less-than-10-minutes-ceb7a434f32e.
Testing APIs with Rest-assured
The first step is to create a Java project in IntelliJ or the IDE of your preference but don’t forget that we will use Gradle for installing the libs and building the project. You can also use Maven if you wish.
Secondly, we need to install the libraries for the project to use Rest-assured. We will also install other libraries for the assertion and define the order of the tests.
Here is the link for the maven repository if you want to install different libraries: https://mvnrepository.com/
Thirdly, start coding.
Initially, you might want to check if your API is returning the correct values (acceptance testing). Therefore, you might also want to check the wrong values (negative testing). Furthermore, what happens if you pass different parameter types or no parameter when the API requires at least one to work correctly? You might want to check it too.
Furthermore, it would be nice to know each case’s expected response beforehand, like the response the API will return for successful requests and not successful ones.
Expected response messages
Here is a list of messages that will return depending on the case:
With these messages above, we can create different tests for each case.
Create your test class
As shown below, the class TestEmployees will contain all our tests, and it is inside of the “src/test/java/api” package.
List of endpoints
From the API tutorial, we have the following list of endpoints that connects to the Employee database.
Using the rest API from the project linked to this tutorial, you can use the following address to define the primary endpoint address. Otherwise, you can define your primary address for the different API you are using.
If only the status matter
Let’s say that you only need to test if your endpoints have the status code 200 and possible responding fast. So you can do a status and latency check. Like the example below:
The code above is covering the get employees endpoint in both latency and status code (200). Although you can also merge both checks, it is more understandable for this tutorial to be separated.
Starting from the most straightforward endpoint
In this case, getting the list of the employees available, let’s check if it returns the structure we need.
For comparing the structure of the response, we use schemas. The schemas are files with a specific configuration that tells how the response should be, and if it has attributes like ID, Names, etc., the schema specifies the types of those and which ones are required to have in the response.
For example, the following code block is the schema of the employee’s endpoint response above:
Extra: To generate schemas, you can use any online site that transforms the response into a schema, create it yourself, or generate it with some tool, .e.g.: https://pypi.org/project/genson/.
Set your schema into the resources folder in your project because it enables you to refer to the file in any part of the code. The following example shows how to compare the response with the schema:
Now you can execute it, but remember to turn up the rest API before triggering the test.
It should give you a positive result.
Creating and deleting employees
For creating an employee, you can pass only the names, and it will get created. How do I know that? The database requirements for inserting an employee requires only the names, and the API is only checking if these fields are in the request.
And the rest of the attributes?
When the test above gets triggered with only the names set, all other attributes get no value (null).
If you want to have all the fields fulfilled, you can copy and paste the following code to set the JSON object with the correct values:
To delete an employee in this case, you need the ID number. As we can see above, we can use ID number 14 to delete the employee created in the previous test.
Note: The path delete/last doesn’t have the ID number from the employee created. Instead, it searches for the last created employee and deletes it. It is a different endpoint created only for this tutorial example. The right endpoint for deleting with the ID number is delete/<id> , meaning that to delete employee ID number 14, it would be, delete/14. As you will see below, the endpoint path delete gets called for other testings.
Schemas for everything
The tests above can get done with schemas as well. Like for every response, you would have a created schema in the resources like the first test.
So in your code, you could do something like this:
Get employee data
The get employee data endpoint is a perfect example of schema comparison. It has many attributes and would be easier to implement by using a schema for testing.
Let’s call the endpoint and request ID number 3 like employees/data/3
The response above shows different data types for the attributes, like dates, numbers and texts. Therefore, the schema should declare these types accordingly:
And you can repeat the comparison code showed in other examples but referring to the schema of employee data in the resources:
Covering other cases
As you can see so far, we covered most of the endpoints. But what if we try creating an employee without one of the names?
What if instead of the date format “yyyy-mm-dd” using “dd.mm.yyyy”?
Or a different value type?
And if we try to use any text instead of ID numbers for deletion and getting employees data?
Note: All the API responses listed are very generic for the purpose of this tutorial.
One more thing, ordering tests
You might have now questioned yourself about the order of creation and deletion. It would be best if you made sure that the employee created is deleted, so the deletion method is called after the creation and not the opposite.
For that, you can use the annotation Order.
That is it! Congratulations for getting so far :)
Why using this framework?
- Rest-assured is super easy to understand and use.
- It brings flexibility and productivity to the development and test process.
- Everyone can use it, given its high readability regarding methods.
- It has clear documentation and many examples on the internet.