Docker Integration Test Strategy

Using Docker containers for integration testing is great, but there are two logical ways to approach it:

• Using docker compose
• Using a Docker API wrapper such as testcontainers or docker-java (other languages have their own wrappers too)

You can also use both together. The testcontainers library has limited support for launching from a compose file. Similarly, if you manually launch via docker compose you could then use the docker-java library to control the containers from within your tests.

When troubleshooting tests, I've found the docker compose route to be nicer because you can launch the containers you need and leave them running while you run your tests over and over. With the testcontainers approach you're constantly stopping and starting containers each time you run tests, which is slow. This is a recognized problem with a reuse workaround, but it's clunky.

Another advantage of docker compose is I'm already using it for development and demo purposes. Using docker compose for integration testing means I don't need to learn a wrapper API and all it's idiosyncrasies. This is even more valuable if you're using multiple programming languages and you're trying to use a common strategy for integration testing. For example, I have Java, Python, and NodeJS apps. It would be nice to have a common way to run integration tests. The testcontainers API for each language is slightly different (and feature support varies too). The compose file format is the same regardless of project language.

Note: This has been discussed before here.

Note: integration tests should be able to run easily on a CI server such as GitHub Actions, plus on a local workstation during development.