See https://github.com/spring-projects/spring-boot/issues/35223#issuecomment-1531061583
Comment From: scottfrederick
@AdrianHarenczyk Thanks for getting in touch. Your question seems off-topic for this issue related to documentation, and as mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements. This feels like a question that would be better suited to Stack Overflow. Please post your question there.
Comment From: wilkinsona
We should also document problems that can be caused by the combination of using @Testcontainers and the test context framework's caching. The former will stop containers in an after all callback, whereas the latter may cache a context that will then be reused later on and will attempt to access a service in an already-stopped container. See #42854 for an example of this problem.
Comment From: hscholz
Maybe it would be a good idea to start with the documentation of @ImportTestcontainers? It solves at least the use case of #42854. At least it took me quite some time to find this alternative, which works for my use case quite well.
Comment From: wilkinsona
It's already documented. What did you have in mind, @hscholz?
Comment From: hscholz
I was looking at the testing documentation:Testcontainers There it is not mentioned and I obviously didn't look further since nothing else is mentioned there. And since my use case was about testing I didn't look there. At the very least just a link to it would be great. But I think it would be even clearer, if most of the documentation of the Development-time Services of TestContainers would move to the Testcontainers page and only the part of how to use it for development with the DevTools and the idea to create a TestApplication would belong to the Development-time Services page.
My use case is Integration Testing exactly like in #42854.
Comment From: hscholz
Maybe to elaborate on the use-case: Spotify described it quite well here
And one additional benefit of this: it usually replaces starting the application locally since you can easily debug from these tests and it even automates all the steps I might have to prepare to get to the specific scenario, e.g. a specific order of messages arrived or a sequence of REST calls.
And the third topic for me is to test that my use the framework (still) does what I expect. A lot of things are handled by the frameworks used, starting with Spring itself, e.g. Exceptions translated into HTTP error codes, but also things like Spring Data. This gives me quite a lot confidence both for the feature itself as well as for updating my dependencies.