Document known testcontainers lifecycle issues

[philwebb]

See #35223 (comment)

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

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

[wilkinsona]

It's already documented. What did you have in mind, @hscholz?

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

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