In this article, you’ll see a simple and scalable way of testing the integration of microservices that enables development speed. To get the most of this article you should be familiar withJenkins,Drone,Docker, and themicroservice architecture.
Let’s assume we’re building a payments platform. This platform will use threeRESTful microservices:users-api,cards-apiandtransactions-api. Theusers-apiallows our platform to register users. Thecards-apiassigns cards to those users. Lastly, thetransactions-apihandles the payments made when users swipe their cards.
But first, unit tests ☝️
To better understand Drone, let’s look at how you would run unit tests for theusers-apimicroservice (the other services would run their unit tests similarly).
Let’s assume theusers-apimicroservice is a Java app built usingGradleand uses aMySQLdatabase managed byFlyway. This is what the Drone file (.drone.yml) would look like to run all unit tests.
- name: unit-tests
- gradle flywayMigrate # setup the database
- gradle test # run unit tests
- name: users-database
Hopefully, this begins to show the power of Drone. In Jenkins, we would have to install Docker on our server and write Jenkinsfiles to setup pipelines that spin up containers — Drone does that automatically for us. All we provide are the Docker images.
Finally, integration tests 😎
When the unit tests pass, we know our service works as expected in isolation. But, what about its integration with the other two services of our platform? This is where integration testing comes in. Let’s say I have an integration test that creates a user, creates a card and simulates a transaction using that card. At this point, that test would fail because theusers-apimicroservice can’t communicate to acards-apiortransactions-apimicroservice.
Drone allows us to add multiple items in the “services” section of the “.drone.yml” file.
The result after we add the cards and transactions microservices to the “.drone.yml” file
Each microservice needs its own database, so those must be added as well. Now, if we had that integration test that creates a user, assigns a card to the user and simulates a transaction, that test would pass because all of the microservices can communicate with each other.
A word about Docker images ⚠️
The Docker images used for the containers that run a microservice (e.g.docker.mycompany.com/cards-api:latest) are essentially environments with a file system that contains the repo of the microservice and a script that spins up the microservice. The microservice can be spun up with a specific configuration that can be modified via environment variables(e.g. branch name, database host etc).
When the Docker container starts up, the initialization script runs and it spins up the application with the configuration provided. Creating and maintaining these Docker images is something that would have to be done for each microservice.
Join us! 😄
My journey atMarqetaso far has been incredible. I wouldn’t have had the opportunity to learn all of this (and much more) without my team’s support.