The status is related to the outcome of the test. From the list of all jobs finished is possible view immediately the status of each job, if passed or failed. The image above has been taken from here. Let's see the outcome of the CI pipeline job. The integration with Gitlab CI has been discussed to overcome this. The outcome is rather simple to understand, but has the limitation of manual execution for each request. Here for example the screenshot obtained launching the GET request. This is valid for both the requests in the Collection.Īs soon as the request will be exectued, the result of the test will be presented immediately. Once the Collection has been imported in the Postman tool, is sufficient send the request to see the tests executed. I have prepared two requests representing the test cases:īoth the requests have their tailor made list of tests. In this case, the result will be reported via cli.Įnter fullscreen mode Exit fullscreen modeįor convenience I have chosen to upload the file inside the test folder of the project, for that reason the docker volume argument mount the directory /test on the host inside the container. These two parameters are respectively named pwd_path_collection and name_of_collection_extracted in the command below. Be careful to use the proper path and the proper Postman Collection extracted as a json file to pass to the docker command. The easiest solution could be trigger it using its postman/newman docker image. Newman is a command-line agent that runs the entire list of requests contained inside the Postman Collection executing the tests, if any. As endpoint I used httpbin, which has the advantage of providing a predictable responses each time a request is sent. The list of test to be performed are included inside that json file, it could be easily downloaded and imported into the Postman tool as a new Collection to evaluate the content. There are many possibilities and useful functions to preare a full test case and investigate in depth each response for semplicity I selected the easiest test/assertion cases as you can see in the HttpbinForNewman.json file. This is a NodeJS module through which the developer can manipulate each request presented on the collection. The test tab has been created for develop a specific test / assertion cases for each request the guidelines are well documented here, on the Postman Collection SDK. In particular the REST request returns a predictable response: its payload is created extracting the details of the request received.įor those who like me have used Postman to send a REST request and analyze the response received, will be happy to know that there is much more to discover inside that tool. Without a real API service to test, the response has been simulated using httpbin as endpoint. To those who are interested, a specific Gitlab repository has been created in order to investigate more thoroughly the solution presented here.įeel free to take inspiration from that if you find it useful. The status of each job will be related to the result obtained by the test. In this case, the CI will be devoted to execute automatically the requests contained inside the extracted Postman Collection, evaluating the results of each test. For every change submitted, Gitlab is able to run a pipeline of scripts to build, test and validate the code changes. CI: Gitlab has its own section for Continuous Integration.It takes as input the Postman Collection extracted as a json file and return the responses with the results of the each test, if any. Newman: is a command line agent that allows to run multiple requests sequentially.The tool is used to send requests and inspect the responses, in order to easily debug the behavior of the API service during its development. First of all the Postman Collection and its test tab, then the dockerized Newman command to run all the requests automatically in sequence and finally the integration with Gitlab preparing an ad-hoc gitlab-ci.yml file to execute all the test using the CI pipeline after every change pushed. Along these few lines will be presented the agents involved and how to integrate every part. The solution leverage the features offered by the Continuous Integration tool built into Gitlab. The purpose of this article is to present a simple procedure to test automatically the service API response.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |