We are today on the era of microservices and, with the emergence of this new architecture, monolithic services are being abandoned. But with so many services of this kind, a worrying issue emerges: testing. How to perform unit testing of a resource present in a REST API? How to perform integration tests of microservices? These are some questions that arise in everyday life and make the construction of tests somewhat challenging for the developer. So, in order to help them, I'll share some frameworks, tools and tips on how to perform such tests.
When creating our test scenario for the API, we should fully know its contract. An API documented with Swagger helps a lot in these times, through which we can know the features, message body, etc.
Data for a request:
Data for a response:
Request behavior:
After collecting this data, we already have a scenario and will know what behaviors are expected in our API.
After the survey of the main points to be tested in an API, it is necessary to choose the tool to perform the tests. Currently, the market offers a variety of tools, but it is necessary to choose the one that best suits the scenario of your project.
As an example, we can list:
In this article we will use Postman to create the tests and Newman to run the tests automatically, so it will be possible to set up a very interesting scenario to test.
Postman is a very popular REST Client among developers who need to make an HTTP request, which helps to validate the tests performed.We also have Newman that runs Postman collections by command line, which facilitates the use of continuous integration software helping to validate an API after generating a build.
To show how easy it is to use Postman, we will create a step-by-step to test the API. This API is very simple - it is a Task CRUD, where we will find the following features:
Our plan will be as follows:
Rule Expected result
POST /tasks with missing values return invalid request status HTTP Status 400
POST /tasks when running return creation status and with location in the header HTTP Status 201, Location no header
GET /tasks when running return ok status HTTP Status 200
GET /tasks/{taskid} with valid taskid return task object and ok status Task Object and HTTP status 200
GET /tasks{taskid} with invalid id return status of not found HTTP Status 404
DELETE /tasks/{taskid} with valid id return status of no content HTTP Status 204
After the construction of the test scenario is finished, we can start using Postman to create the test scenarios. To begin, we have two options: import Swagger or create a new collection.
Import Swagger
Create a new collection
To generate collections of test requests on Postman, we can import a Swagger document or generate a new collection through the tool itself. The import will bring all the requisitions described in Swagger, while the creation of a collection will generate empty requisitions, requiring the developer to describe the items in the collection.
Collection created with the requests that we will test
With Postman, we have the possibility to work with several environments, such as Production or Sandbox. In each one of them, we can put variables to help in the tests. A good example is the insertion of the API endpoint.
Environment Configuration.
To create the tests, select the HTTP method (POST, GET, PUT, DELETE, etc) and type the request URL, notice that the URL {{uri_task_api}} is an environment variable, so we can test several environments.
Add the necessary Headers, in this case we have to run the "Content-Type" Header to specify that we will run a JSON, but we could run a different Header to test if the API is handling the "media type" error correctly.
When we are carrying out a data inclusion or editing operation, we should fill in the body. This is an example of a body using JSON. Besides JSON, we can use XML, text, form-data, x-www-form-urlencoded or binary files.
In the "Pre-request Script" tab it's possible to run scripts before making a request, in this image we are creating a "createdAt" variable with the current date, and adding it in an environment, so we can use this value anywhere in the request.
In the "Tests" tab is where we should create the scripts to validate the test scenario, validate if a status code is according to plan, if the Header "location" is present, among other possibilities. We can also retrieve values to be used in the future, i.e. we can perform several scripts, depending on your needs.
After creating all the scenarios, we have the possibility to run the test individually or to the entire collection. In the unit test, you just have to click the following button:
. This button will activate your request and validate your tests, and inform you which tests have passed or failed.
To run the collection go to the "Runner" menu. It will open a Window, where you must select the collection and the "Environment". After that just click on the following button:
. It will start all programmed requests in your collection, and inform you which tests have passed or failed.
As mentioned above, we have Newman that runs your Postman collections by command line; this is very useful when you want to leave your tests as a step in your build. To use it, just export the collection and the desired environment from Postman.
Export collection.
Export Environment.
To run on the command line, simply type the following:
newman run tasks-api.postman_collection.json --environment task-
environments.postman_environment.json
After running, it will display the results with the tests performed and show which test passed and which failed.
Well, this is one of the ways you can test your API. Of course, there are several tools and methods, all you have to do is understand what is best for your context, and never leave your APIs untested.
GITHUB: https://github.com/renanpetronilho/task-api
Our API Management Platform is a complete hub. With Sensedia, large companies scale their operations with APIs, with test environments, adaptive governance, API security and much more.
Post originally published in July 2017, with minor updates in 2019.