5 ms·

I did not come in here expecting to read such effusive praise for testcontainers. If you’re coming from a place where docker wasn’t really a thing I can see how

• dustedcodes 3y ago
  > The library has the nasty habit of assuming it’s running on a host machine and nothing else docker related is running To be honest given that most tests run as part of an isolated CI/CD pipeline this is a very reasonable assumption to make.
• cdata 3y ago
  I would guess that this speaks to an unattended (developer) user story related to other workflows, or perhaps the container-adjacent ecosystem overall. Testing with any workflow is always tricky to get just right, and tools that make it easy (like, "install a package and go" easy) are underrated.
• simonkagedal 3y ago
  Testcontainers is not shelling out to the docker CLI; at least on Java, it is using a Java implementation of the docker network protocol, and I believe that’s the case also for the other platforms. Not sure this matters for the core argument you are making, just thought I’d point it out.
  • doctorpangloss 3y ago
    The comment you are replying to makes so many mistakes about how Testcontainers works on Java that I'm not sure what source code the commenter is looking at.
    • perbu 3y ago
      Why don't you point them out, please. We already know about testcontainers not using the shell, but rather talking to the HTTP API. Making comments like "this is wrong, but I'm not gonna explain why" has no place here, imho.
      • dventimihasura 3y ago
        > Making comments like "this is wrong, but I'm not gonna explain why" has no place here, imho. Who are you quoting?
        • saghm 3y ago
          Using quotation marks as a way of summarizing what someone might say but didn't literally say is a fairly common practice. I think the quotation is a fairly accurate depiction of the sentiment in the comment it responds to, so I don't see any issue with it.
          • dventimihasura 3y ago
            It may be common, but that doesn't mean it's warranted. Logical fallacies, for example, are also common (so are spelling and grammar mistakes), and yet personally I prefer to commit them less often rather than more often. You think the quotation is a fairly accurate depiction of the sentiment expressed by another person. I don't think that. In fact, I think the opposite. One way to settle the matter would be to ask the person. What do you say, doctorpangloss? Do you think this is a fairly accurate depiction of the sentiment you were expressing? "this is wrong, but I'm not gonna explain why" I doubt this person will respond, of course (they're not obliged to).
• choeger 3y ago
  Came here with exactly this on my mind. Thanks for confirming my suspicion. That being said, having specific requirements for the environment of your integration tests is not necessarily bad IMO. It's just a question of checking these requirement and reporting any mismatches.
  • eecc 3y ago
    except the parent is wrong (at least the Java impl). see: https://github.com/testcontainers/testcontainers-java/blob/main/core/src/main/java/org/testcontainers/dockerclient/HeadersAddingDockerHttpClient.java https://github.com/testcontainers/testcontainers-java/blob/m... https://github.com/testcontainers/testcontainers-java/blob/main/core/src/main/java/org/testcontainers/dockerclient/UnixSocketClientProviderStrategy.java https://github.com/testcontainers/testcontainers-java/blob/m...
    • withinboredom 3y ago
      Their details might be wrong, but were perhaps not always wrong. Either way, the spirit of their argument is clearly not wrong.
      • xienze 3y ago
        > the spirit of their argument is clearly not wrong. Uh, the jury’s out on that seeing as how the parent didn’t give any specifics other than some hand waving about “issues with other containerized workflows.” OK, elaborate on that please, otherwise the parent isn’t really making a valid point or may be misinformed about the current state of Testcontainers w.r.t. to these vague “other containerized workflows.”
        • withinboredom 3y ago
          yet people are showing up here and agreeing completely. So, it seems common enough not to need elaboration.
          • 3y ago
• rollulus 3y ago
  Does anyone happen to know which testcontainer implementations shell out, if any?
  • nrabulinski 3y ago
    Seems like the „community-maintained” ones they endorse, like the Rust implementation, do I did not realize Rust wasn’t officially supported until I didn’t go to their GitHub and see in the readme that it’s a community project, and not their „official” one
• Jnr 3y ago
  Similarly to CI agents, I run them in docker-in-docker container, which makes it a lot harder to break anything on the host.
• theK 3y ago
  I have had a similar intuition from when trying out testcontainers some years ago. I do not know how the project has developed but at the time I tried it it felt very orthogonal or even incompabtible to more complex (as in multi language monorepo) projects, cde and containerized ci approaches. I do not know how this has developed since, the emergence of cde standards like devcontainer and devfile might have improved this situation. Yet all projects I have started in the past 5 years where plain multilingual cde projects based on (mostly) a compose.yml file and not much more so no idea how really widespread their usage is.
• razemio 3y ago
  Never had any issues. We have 100+ build jobs running on Jenkins and most of them have some Testcontainer tests. These never collide if implemented correctly (randomised ports with check for e.g.) even when run in parallel. On my machine running several docker dev environments it was also never an issue. Can you specify what issues you had? Also I am pretty sure the library does not work as you describe. Isn't it using the Docker Engine API? I could be mistaken, never checked the source code. Edit: Just checked the documentation. According to the docs it is using the Docker API.
  • btreecat 3y ago
    > We have 100+ build jobs running on Jenkins and most of them have some Testcontainer tests. That's probably why you can and do use it, Jenkins. Jenkins let's you install w/e on the hosts where as more modern systems default context is a docker container or at least speak it natively. > Can you specify what issues you had? Some of my devs have coded tests containers into their ITs. These are the only pipelines we can't containerize, because test containers don't seem to work inside docker, and won't work in k8s either.
    • razemio 3y ago
      Ah! That is not an issue of testcontainers. In our Jenkins every pipeline it dockerized and uses agents. So it is not running on the host directly. However it is also not running dind (Docker in Docker). Instead it is important to use dood (docker out of docker), which is best practice anyway. Your CI needs to be configured once and all your problems should go away IF tests have randomised ports or even better also run in docker so that those ports do not need to be exposed on host level. Most of my colleagues however prefer not to use dev containers so randomised ports was the solution for us for now.
      • SOLAR_FIELDS 3y ago
        Just as an example, Gitlab is (was?)kind of infamous about this - everything you do in gitlab for a long time was already in docker, so you by nature of running in gitlab were forced to do everything in DinD mode. They might have changed this in recent times.
• fuzzy2 3y ago
  I'm interested to hear what you would do instead! I'm using Testcontainers in a very basic scenario: A web app with a PostgreSQL database. There are different database backends available (like Sqlite) but I use PostreSQL-specific features. Currently, in my integration testing project, I use Testcontainers to spin up a PostgreSQL database in Docker and then use that for testing. I can control the database lifecycle from my test code. It works perfectly, both on my local PC and in the CI pipeline. To date it also did not interfere or conflict with other Docker containers I have running locally (like the development database). From what I gather, that is exactly the use case for Testcontainers. How would you solve this instead? I'm on Windows by the way, the CI pipeline is on Linux.
  • piokoch 3y ago
    There is no alternative if you want Postgres "embedded" within your test, I have researched that for a long time, as full PGSQL as Docker image sounded as overkill, but nothing else exists.
    • fuzzy2 3y ago
      I think grandparent’s concerns were not with using Docker in general but instead with how the Testcontainers library orchestrates it. I assume there’s an alternate approach behind the critique, and that’s what I’m interested in.
      • SOLAR_FIELDS 3y ago
        I've been using Dagger to do container service lifecycle as the API is pretty powerful. But some other alternatives, depending on your use case - Some CI/CD support container orchestration e.g. Github service containers. This is my usual recommendation for CI setups. You're unlikely to get local runs this way though. It also has a lot of similar limitations to testcontainers - If you're building for Kube, managing the container lifecycle and services with kube is probably going to be more straightforward than docker networking stack. You can run a minikube and spawn your containers in it, for example. Then your client library that was previously running testcontainers is simply making kube calls. This gives you much more control over the container lifecycle - If you're not spinning up and tearing down containers repeatedly (I've seen people just use the same container in unit tests as a service and just wipe it. Often for performance reasons to avoid the overhead of spin up and tear down), just bootstrap a compose file before running your tests. Sometimes testcontainers is really going to be the best solution for your problem though. One common use case is if you need to spawn a LOT of the same container over and over for your unit test suite, and it has to be a fresh container. My advice is to try to isolate this part of the pipeline from the rest as much as possible if you have to do this.
• 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 ago
    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
• vivzkestrel 3y ago
  explain what "any other containered workflow" encompasses