Our migration to concourse means we no longer run all integration tests. If we create an image that starts Redis/Cassandra etc we'll get more coverage.
If the intention is to run tests that need Redis/Cassandra, you might want to consider TestContainers, which Zipkin uses for integration testing with Cassandra, Elasticsearch, MySQL, and RabbitMQ. It would require some changes to all the integration tests using these, but you could then run the integration tests anywhere that can run Docker, including locally.
There is a bit of spring cloud involved into startup, but you might want to check this out:
https://github.com/Playtika/testcontainers-spring-boot
It's early days, but I'm not enjoying the TestContainers experience thus far. I'm going to re-open this so that we can revisit things.
If we stick with TestContainers, there are a few improvements that I think we should make:
latest images as it means our builds are not repeatableI'm not sure we'll get that far though. Right now, I can't build things locally as my local Docker environment is found, but the containers either timeout when starting up (Cassandra) or start but then aren't actually listening (Redis).
@wilkinsona We're using TestContainers quite heavily for integration testing in Spring Session and are quite happy with it.
If the container timeouts for you starting up, you should consider using withStartupTimeout when configuring container, as the default timeout is 60 seconds IIRC. For the other (not listening) problem it sounds like a configuration problem.
For the reference, here are a few samples to what we do with TestContainers (no latest image and no hardcoded ports used):
I've made some progress by blowing away my Docker Toolbox installation and using Docker for Mac instead. It remains to be seen what effect that's had on the integration tests for the launch script…
Perhaps we can set a CI environment variable and use an assume check so that these only run on CI for now.
Also +1 to using tagged images for repeatable builds.
+1 for not using latest images. If we didn't use hardcoded ports, we would need to get the port from container.getFirstMappedPort and I'm not sure how that would work with SpringRunner.
If we didn't use hardcoded ports, we would need to get the port from
container.getFirstMappedPortand I'm not sure how that would work withSpringRunner.
@mbhave See the last example from my previous comment.
thanks @vpavic. We'll give that a shot.
Hi @wilkinsona,
It's early days, but I'm not enjoying the TestContainers experience thus far
TestContainers member is here and I'm here to help you :)
Let me know if something is not working or you see a room for the improvements!
Thank you very much, @bsideup. Things have improved considerably since switched from Docker Toolbox to Docker for Mac. AFAIK, my Docker Toolbox installation met all of the requirements for TestContainers but it was not working reliably. Unfortunately, I lacked the time and expertise to diagnose exactly what the problem was so I went for the nuclear option of switching to Docker for Mac.
@wilkinsona
The option you chose is solid and recommended by us :) 👍
While we still nominally support the Docker Toolbox (or, to be more precise, docker-machine), Docker for Mac provides better UX and stability.
Also, the majority of TestContainers' developers use Docker for Mac to develop TC itself.
I'm writing this in case you want to provide some recommendations for the Spring Boot contributors on "How to start with Docker testing" topic :)
I'll keep watching this issue if you or anyone else from Spring Boot team have any questions in regarding of TestContainers and Spring Boot.
There is also StackOverflow tag to ask general questions:
https://stackoverflow.com/questions/tagged/testcontainers
Slack to discuss things:
http://slack.testcontainers.org
And of course Github issues to report bugs:
https://github.com/testcontainers/testcontainers-java/issues
Most helpful comment
If the intention is to run tests that need Redis/Cassandra, you might want to consider TestContainers, which Zipkin uses for integration testing with Cassandra, Elasticsearch, MySQL, and RabbitMQ. It would require some changes to all the integration tests using these, but you could then run the integration tests anywhere that can run Docker, including locally.