Hello Newman - How to Build a CI/CD Pipeline that Executes API Tests
Hello Newman
Executing automated tests in a CI/CD pipeline can be made simple and easy when using containers. After an image is built and can be started and tested to decide if it is a viable candidate to push to the registry. In this article we will walk through a demo of a GitLab CI/CD pipeline. We will build a simple express REST API application based on a Node image and then execute and verify automated tests against the api by running the application in docker-compose. Automated tests are written in javascript and will be executed in the PostMan CLI tool called Newman. Verifying that the running container can pass automated tests as early in the pipeline as possible is a very good thing. Let's take a look at how to accomplish this.
Prerequisites
Building the Application
We need to start with an example application. For this exercise we will be making a API that returns members of boy-bands. It will be a node app using Express to keep it simple. Create a file named index.js that contains the following code:
1var express = require("express");
2var app = express();
3
4app.listen(3000, () => {
5 console.log("Server running on port 3000");
6});
7
8app.get("/newkids", (req, res, next) => {
9 res.json(["Donnie","Joey","Jordan","Jonathan","Danny","David"]);
10});
11
12app.get("/nsync", (req, res, next) => {
13 res.status(501);
14 res.send("Not Implemented");
15
16});
17
18app.get("/health", (req, res, next) => {
19 res.json("Active");
20});
Also make a file named "package.json" that contains the following code:
1{
2 "name": "ci-node",
3 "version": "1.0.0",
4 "main": "index.js",
5 "dependencies": {
6 "express": "^4.17.1"
7 }
8}
We are going to package the application as a Docker image so we need a Dockerfile. If you need an intro to Docker to better follow along you can get started here. Create a file named "Dockerfile" that contains the following code:
1FROM node:13.1.0
2
3WORKDIR /usr/src/app
4
5COPY package*.json ./
6
7RUN npm install
8
9COPY . .
10
11EXPOSE 3000
12
13CMD [ "node", "index.js" ]
You can now build the application locally with the following command:
1docker build -t ci-demo .
To verify that the application works you can execute the following command:
1docker run -d -p 3000:3000 ci-demo:latest
The application is now available at http://localhost:3000. The following commands should work and return the proper results or status codes:
- http://localhost:3000/health
- http://localhost:3000/newkids
- http://localhost:3000/nsync
Writing and executing automated API tests
There are many frameworks available that will execute automated tests against a REST API. For the purposes of this demonstration we are going to use Postman. Most people are familiar with Postman, or have used it in the past, to test an API manually. Postman also has the capability of creating, editing and executing automated tests against the same API. The tests are written in Javascript and can be imported and exported in JSON format. More information and tutorials are available on the Postman Learning Center.
Create a new directory named api-tests. Within the api-tests directory create a file named "ci-demo.postman_collection.json" that contains the following JSON:
1{
2 "variables": [],
3 "info": {
4 "name": "ci-demo",
5 "_postman_id": "eaba83b1-65f2-e995-adcf-e07477fe67dd",
6 "description": "",
7 "schema": "https://schema.getpostman.com/json/collection/v2.0.0/collection.json"
8 },
9 "item": [
10 {
11 "name": "Check Health",
12 "event": [
13 {
14 "listen": "test",
15 "script": {
16 "type": "text/javascript",
17 "exec": [
18 "tests[\"Body matches string\"] = responseBody.has(\"Active\");",
19 "tests[\"Status code is 200\"] = responseCode.code === 200;"
20 ]
21 }
22 }
23 ],
24 "request": {
25 "url": "http://{{host_name}}:{{host_port}}/health",
26 "method": "GET",
27 "header": [],
28 "body": {},
29 "description": ""
30 },
31 "response": []
32 },
33 {
34 "name": "Check Not Implemented",
35 "event": [
36 {
37 "listen": "test",
38 "script": {
39 "type": "text/javascript",
40 "exec": [
41 "tests[\"Body matches string\"] = responseBody.has(\"Not Implemented\");",
42 "tests[\"Status code is 501\"] = responseCode.code === 501;"
43 ]
44 }
45 }
46 ],
47 "request": {
48 "url": "http://{{host_name}}:{{host_port}}/nsync",
49 "method": "GET",
50 "header": [],
51 "body": {},
52 "description": ""
53 },
54 "response": []
55 },
56 {
57 "name": "Check New Kids",
58 "event": [
59 {
60 "listen": "test",
61 "script": {
62 "type": "text/javascript",
63 "exec": [
64 "tests[\"Status code is 200\"] = responseCode.code === 200;",
65 "",
66 "var jsonData = JSON.parse(responseBody);",
67 "tests[\"Make sure Donnie is in the list\"] = jsonData[0] === \"Donnie\";",
68 "tests[\"Make sure Mark is not in the list\"] = !responseBody.has(\"Mark\");"
69 ]
70 }
71 }
72 ],
73 "request": {
74 "url": "http://{{host_name}}:{{host_port}}/newkids",
75 "method": "GET",
76 "header": [],
77 "body": {},
78 "description": ""
79 },
80 "response": []
81 }
82 ]
83}
Also in the api-tests directory create a file named "ci.postman_environment.json" that contains the following JSON:
1{
2 "id": "6a67c87a-36b4-126c-2696-b6256e7be90b",
3 "name": "ci",
4 "values": [
5 {
6 "enabled": true,
7 "key": "host_name",
8 "value": "app",
9 "type": "text"
10 },
11 {
12 "enabled": true,
13 "key": "host_port",
14 "value": "3000",
15 "type": "text"
16 }
17 ]
18}
The next thing we are going to do is import our tests into the Postman application. To do this we will create a new Collection while importing it by clicking on the "Import" button in the top left. You can either drag and drop the file or click in the window and select your "ci-demo.postman-collection.json" file. Your screen should now look like this:
Click the "Import" button and you should see your collection on the left side of the screen.
Expanding the collection and selecting one of the tests should allow you to then select the "Tests" tab and should look like this:
You can see that this particular test is verifying that a GET call to /newkids should return a 200 response code and the body returned should contain the value of "Donnie". It is also verifying that the body returned should not contain the value of "Mark". These are just very simple examples but there are many more to explore by clicking on the "SNIPPETS" in the right side or by writing your own.
You may have noticed that the URL we are testing has some variables in it. The URL in our tests is actually "http://host_name:host_port". This is because Postman allows for variables to be defined for a particular environment and you can change between them in the top right of the screen. This is important for using this in CI because later when these tests are executed in docker-compose the hostname is going to be a different value than when you execute these tests locally.
The next thing we need to do to allow our tests to be executed locally is to create a local environment configured with our local environment settings. To do this click on the gear in the top right of the screen to get to the "Manage Environments" screen and click the "Add" button. For the name enter "local" and click the "Add a new variable" text. In the "Variable" section enter "host_name" and for the "Initial Value" enter "localhost". The "Current Value" section should auto fill with what you entered for the initial value. Your screen should look like this:
You should now be able to execute your tests locally by selecting your "local" environment you just created and clicking "Send" on your various tests.
Executing API Tests With Newman and docker-compose
We are now going to use the Postman CLI tool named "Newman" to execute the same API tests we just imported. We are going to use docker-compose to start our sample application, as well as the Newman CLI. If you need to get up to speed on docker-compose you can do sohere.
Create a file named "docker-compose.yaml" in the base directory of your project with the following contents:
1version: "3"
2
3services:
4 app:
5 image: ci-demo:latest
6 ports:
7 - "3000"
8 app-test:
9 image: postman/newman_ubuntu1404:4.5.5
10 depends_on:
11 - app
12 entrypoint: [""]
13 volumes:
14 - $PWD/api-tests:/etc/newman
15 command: >
16 newman run ci-demo.postman_collection.json
17 --environment="ci.postman_environment.json"
18 --reporters cli,junit --reporter-junit-export /etc/newman/api-results.xml
As you can see we have one service definition that is our application. The "app-test" service is a image that contains the Newman CLI tool. We are mapping a volume in the app-test service that puts our api-tests directory in the /etc/newman directory which allows us to execute the tests from the default location within the container. We are then executing a "newman run" command and passing the arguments of our tests, what environment file to use, what reporters to output our results and where to write those results. Notice that the name of our applications service is "app". This means that when the Newman CLI is executed it can execute the API tests against the hostname of "app". This is why we have a different environment file that we are specifying that contains a "host_name" value of "app". You can now execute the tests by running the following command:
1docker-compose up --abort-on-container-exit --exit-code-from app-test
If everything worked correctly you should see the output of your tests.
Also, a file should be written to your api-tests folder named "api-results.xml" that is in JUnit test output format.
Creating a Pipeline
To put this all together we are going to put all of these steps in a CI/CD pipeline. For example purposes I have a file for defining a pipeline in Gitlab CI/CD. If you don't have access to Gitlab you can execute similar steps in other pipeline systems. This is an example of how you can build the application and test it when code is committed:
1stages:
2 - build
3 - test
4
5build:
6 tags:
7 - docker
8 stage: build
9 image: docker:latest
10 services:
11 - docker:dind
12 script:
13 - docker build -t ci-demo:latest .
14
15test:
16 tags:
17 - docker
18 stage: test
19 image: tmaier/docker-compose:latest
20 services:
21 - docker:dind
22 script:
23 - docker-compose up --abort-on-container-exit --exit-code-from app-test
24 after_script:
25 - docker-compose down --rmi local --remove-orphans
26 artifacts:
27 paths:
28 - api-tests/api-results.xml
29 reports:
30 junit: api-tests/api-results.xml
Advanced Stuff I left Out
- In a more real world version of a pipeline like this you would want to use a more dynamic tag than "latest" and would also want to pass that as an argument to the compose command.
- You would also push the image to a container registry and then pull it in subsequent steps.
Conclusion
Being able to execute automated tests against your application as early as possible in a CI/CD pipeline is going to lead to a great deal of time saved and a lower defect count. Allowing the same automated tests to be executed both locally and in the pipeline is also a key to making this level of testing functional and useful.
