Fork me on GitHub

Hi, I have tests that that I run (via kaocha) using clojure -M:test. Everything works as expected. My tests require a Postgres database to be present and I have a simple docker command to provide that. Im wondering how people typically incorporate this docker step as part of a test run? It feels like something that should be created as part of a fixture, but I don't see any obvious ‘hooks’ to accomplish this piece if set up. Any perspectives on approaches that work well would be welcome!


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 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.