A few examples of the difficulties I've had with testcontainers: - Testcontainers running in a DinD configuration is complex and harder to get right - Testcon

A few examples of the difficulties I've had with testcontainers: - Testcontainers running in a DinD configuration is complex and harder to get right - Testcontainers needing to network or otherwise talk with other containers not orchestrated by testcontainers - general flakiness of tests which are harder to debug because of the library abstraction around Docker In general if anything else in your workflow other than testcontainers also spawns and manages container lifecycle, getting it to work together with testcontainers is basically trying to reconcile two different configuration sets of containers being spawned within Docker. I think the crux of the issue is that testcontainers inverts the control of tooling. Typically containers encapsulate applications, and in this case it's the other way around. Which is not necessarily a bad thing (indeed, I am a huge proponent of using code to control containers like this), but when you introduce a level of "container-ception" by having two different methodologies like this it creates a lot of complexity and subsequent pain. Compose is much more straightforward in terms of playing well with other stuff and being simple but obviously isn't great for this kind of unit test thing that testcontainers excels at