Test Automation for Docker
This tutorial demonstrates using UP9 test automation with Docker, from installation to execution. It's a great starting point for your UP9 journey.
We will demonstrate how to get an instant test-automation harness for WeaveSocks, a demo microservice application by Weaveworks.
First, a big shout out to Weaveworks for creating such an awesome demo microservice application and making it available. The demo microservice application has 10-20 different microservices performing the various tasks required to operate the demo sock shop.
Let’s start with these steps:
- Install the UP9 CLI
- Install the demo application (WeaveSocks)
- Deploy UP9 on the application's Docker network
- Display a complete test automation harness instantly created for the demo application
We'll need the following prerequisites:
- Docker Compose
Install the UP9 Command Line Interface
First, sign up for UP9 using this link: https://up9.app/signup.
Next, install the UP9 Command Line Interface (CLI) using Node Package Manager:
npm i -g up9
Finally, with your browser open and your UP9 account logged in, authenticate the UP9 CLI:
To install WeaveSocks and verify installation, run the following commands:
git clone <https://github.com/microservices-demo/microservices-demo>
docker-compose -f docker-compose.yml up
Then, open your browser and go to localhost.
To deploy UP9 on the demo application's Docker network, first change directory to the `
docker-compose` folder in `
microservices-demo/deploy/docker-compose`, then run the following command in the
up9 tap:create-docker-compose \[give-your-workspace-a-name]
The operation will take less than a minute to complete, and generate a new YAML file named
This new file contains instructions to Docker Compose to position UP9 containers for traffic observation.
To run the WeaveSocks demo application together with UP9 observing traffic, run the following command:
docker-compose -f docker-compose.yml -f docker-compose-up9.yml up
That’s it. UP9 is now deployed on your Docker network.
For the test automation to be created, we need to generate traffic. Typically, you would deploy UP9 in a traffic-rich environment (e.g. integration), but here everything is deployed on a development environment (e.g. laptop), so we actually have two options to create traffic:
- Manually use the application
- Run a load test (or an end-to-end test)
Luckily, the demo application comes with a load test built in. Let’s run the load test to generate traffic using the following command:
docker run --net=host weaveworksdemos/load-test -h localhost -r 100 -c 2
UP9 automatically generates CI-ready test code by observing the traffic. Here's what you can do next:
- View the Observability in-Test Dashboard
- View the CI-ready test-code
- Execute the CI-ready test-code
- View the reliability analysis
Observability in Test Dashboard
The Observability-In-Test dashboard provides observability and relevant insight to the engineers involved in the practice of testing. The dashboard will include information related to test planning, creation, maintenance, execution and analysis.
Service Topology and API Contracts
In the Observability-In-Test dashboard, we can look at the service topology and API contracts.
Finally, we can view the CI-ready test code that is automatically created. The test code provides full coverage of the business logic.
The CI-ready test code includes a sequence of API calls, traversing the business logic graph satisfying dependencies and asserting results. A sample test code snippet looks like this:
If we consider a certain test flow that is part of the business logic:
This is the test code that is used to validate the test span:
As you can see it includes the sequence of service endpoint calls, data extraction, and assertions.
Now that you have ready-to-run test-code, run it against the demo application. As you recall, the application is installed on a laptop in a Docker compose setup.
Earlier, when we deployed UP9, we also deployed a test runner. All you need is to point to it by selecting it in the RUN dialog:
When you execute the test code, it runs against the demo application that is installed on the laptop without any further assistance.
Once the test code is executed, you can view the resulting reliability analysis:
Root Cause Analysis
When you’d like to address specific failures and see what caused them, you can take a deeper look:
For example, you can see that a certain failure was caused by an assertion where the response code was expected to be 201 and it was 200. You can dig deeper into the HAR payload to see exactly what happened:
For support, feel free to use any one of the three: