Integration Tests with GitHub Service Containers
A tutorial on running integrations tests with dependencies in Github Actions workflows.
Not so long ago we published an article about using Testcontainers for emulating external dependencies such as a database and cache for the purpose of backend integration tests. The article also explains the different ways of running the integration tests, environment scaffolding and their pros and cons.
In this post we want to show another alternative in case you use GitHub Actions as your CI platform, which became the most popular CI/CD solution at the moment.
It’s called Service Containers, and we realised that, unfortunately, not so many developers are aware of it.
In this hands-on tutorial we want to demonstrate how to create a GitHub Actions workflow for integration tests with external dependencies (MongoDB and Redis), using the demo Go application we wrote previously, as well as review the pros and cons of GitHub Service Containers.
What are Service Containers?
Service Containers are Docker containers that offer a simple and portable way to host dependencies like databases (MongoDB in our example), web services, or caching systems (Redis in our example) that your application needs within a workflow. This article focuses on integration tests, however there are many other possible applications. Service containers can also be used to run supporting tools required by your workflow, such as code analysis tools, linters, or security scanners.
Why not Docker Compose?
Sounds similar to services in Docker Compose, right? Because it is.
However, while you could technically use Docker Compose within a GitHub Actions workflow by installing Docker Compose and running the docker-compose up, service containers provide a more integrated and streamlined approach specifically designed for the GitHub Actions environment.
Also, while they are similar, they solve different purpose.
Docker Compose is good when you need to manage a multi-container application on your local machine or a single server. best suited for long-living environments.
Service Containers are ephemeral and exist only for the duration of a workflow run, and defined directly within your GitHub Actions workflow file.
Also, the feature set of service containers (at least as of now) is more limited compared to Docker Compose, so be ready to discover some potential bottlenecks, we will cover some of them at the end of this article.
