Well, if you have "local services" as dependencies and have not mocked all DB (which, by the way, I highly don't recommend to do) you'll probably need to have these services available... There may be a way to start docker containers via code, but I don't really suggest doing that. Maybe a script that calls docker-compose and then assume that the user will run this script before running the tests?

So at the CI you could run the same script before any tests too

Thanks for the reply. Yes, I feel better to use a real Postgres instance for my test rather than a mock - docker makes this very easy and it helps cover a whole category of potential bugs that could otherwise go unnoticed. Running the docker command pre-test run is no big sacrifice - I can add a shell script to bring the whole thing down to a single command - I wanted to make sure there wasn't any well known pattern to do this sort of stuff already in place.

Our CI pipeline starts by spinning up the necessary services in Docker (Redis, Percona, Elastic Search x 2) and then runs the tests. It's a mix of bitbucket.yml and shell scripts and clojure commands. I think that's reasonable.

We use tools.build to automate a fair bit -- the full DB migrations from an empty DB up to "now" and then all the tests in whatever combinations we need, and JAR building and uploading to S3 for deployment.