Here is an idea that you can use as a base for your company!
Some years ago I wrote
this article
about Integration Test Strategy for REST Services.
Thing is that, three years after, this same theme is pretty important, even
more now. With the adoption of more Distributed Services Architecture, most
using REST API's, we have the necessity to ensure that the health of our
services are good.
This is a proposal about how it's possible doing this approach for your
services.
Objectives of this Example
The final version of this solution will enable us to change the code of some
API, push to the repository and run automatically the integration tests,
generating the necessary reports:
For this article, we will focus on getting API and Jenkins running on
your machine, and configure Jenkins to run the integration
tests.
Step 1 - Creating and Running the Docker Containers
The easier way to get the services running is to download this example. You must have Docker installed on your machine.
Open the command line in the root directory of this project and run the
command:
docker-compose up
The result will be three new containers running in your machine:
-
dns-server: a tool to resolve names of local Docker containers on the host (only
working for Linux machines);
-
api: a simple API, written in Python with Flask,
with a GET endpoint that simulates the return of Customers;
-
jenkins: an instance of the Jenkins automation server, that
will automate the integration tests for us.
You can test the API using Postman. Import the file Customers_API_Tests.postman_collection.json present in the project and
run:
Just one observation. For Windows machines, to run locally the API you
should use the URL http://localhost:5000/customers
Step 2 - Jenkins Initial Configuration
When the Jenkins start in your machine, it will provide a code that is
the password for your Admin user first time. It's important that you
maintain this password with you:
You can access the address http://localhost:8080. This screen will be
shown:
As a matter of test, you can continue as Admin, and use the
installation of the default plugins. Let's maintain the default
address too.
Step 3 - Jenkins - Add support for Newman
To use Newman internally in Jenkins, you should install support for
NodeJS. Go to Manage Jenkins -> Manage Plugins -> Available tab
-> NodeJS Plugin
Now, go to Manage Jenkins -> Global Tool Configuration -> NodeJS
-> Click in NodeJS Installations. Add this configuration, with a name
that you can use to identify this version of NodeJS with Newman package,
in your future items:
Step 4 - Create and Export Integration Tests from Postman
Now, it's time to get the results of our integration tests and create
a relationship with your Jenkins instance. Go to Postman, where you
have the Customers_API_Tests collection imported. We have some
examples of tests here, you can add more as you wish:
Let's export this collection to use in the integration tests. Just one
tip is, every time you change the tests, save the content here and click
Update Link.
Another thing is that you must have your tests pointing to
http://api:5000/customers, instead of localhost:5000. This is because
the containers can see each other based on this name. So, if you are
using Windows to test the containers, don't forget to change it, before
saving the tests and export the Collection Link.
Step 5 - Add Integration Tests in your Jenkins
Let's not use the result of these tests directly into Jenkins. Create
a new Item of type Freestyle project, adding a name for it:
Go to the Build Environment section of the item, and add the name of
the NodeJS installation you had configured before:
In the Build section, add the command:
newman run <address of Shared Collection>>
Step 6 - Let's Run It!
Finally! Save everything and use the option "Build Now" of the item
created. You will see that execution will start, with the hash symbol and
the number:;
If you enter in the execution -> Console Output, it's possible to
view the result of the integration tests directly inside Jenkins:
You can just change something directly in the API like in the example
below, where I've changed the test to verify a different name. It'll break
the tests.
Now you will see that one of the tests are failing:
No comments:
Post a Comment