3 ms·
could you elaborate what limitations does is have? how this does not play nice with remote docker/other docker containers? I don't know this library but it loo
by Szpadel 3y ago
could you elaborate what limitations does is have?
how this does not play nice with remote docker/other docker containers?
I don't know this library but it looks like something that I started writing myself for exactly the same reasons so it would be great to know that's wrong with this implementation or why shouldn't I migrate to use that, thanks
- SOLAR_FIELDS 3y agoA 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