Live data from Hacker News

Testcontainers

testcontainers.com

251–260 of 260 posts

Re: Testcontainers

#251

Earlier quoted context omitted.

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 r…

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.

I think as long as you can expose the docker socket (should also be possible in gitlab) you can use dood. Dind has never worked out for me. Sooner or later there will be issues.

Re: Testcontainers

#252
post #243

Earlier quoted context omitted.

> Making comments like "this is wrong, but I'm not gonna explain why" has no place here, imho. Who are you quoting?

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.

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

Re: Testcontainers

#253
post #243

Earlier quoted context omitted.

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.

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 t…

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

This works both ways; your questions phrasing assumed that the person you responded to felt the same way about how quotation marks should be used. It seems likely that you knew the answer was that they weren't intending to literally quote anyone, but you didn't ask them about that first, which is why it comes across as passive-aggressive.

For clarity, this is the comment that the quote was referring to:

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

The comment quite literally calls something wrong ("The comment you are replying to makes so many mistakes"), and it doesn't give any evidence to the claim that there are "so many mistakes" to explain this. When someone says one thing and then claims that it shouldn't be taken literally because they intended something entirely different, that's called gaslighting.

Re: Testcontainers

#254
post #253

Earlier quoted context omitted.

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 t…

> 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. This works both ways; your questions phrasing assumed that the person you responded to felt the…

> your questions phrasing assumed that the person you responded to felt the same way about how quotation marks should be used.

Questions don't assume things. People do.

> The comment quite literally calls something wrong ("The comment you are replying to makes so many mistakes"

Yes, but it doesn't literally say, "I'm not gonna explain why." Why did you omit that part?

Re: Testcontainers

#255

been doing this for years, I would not say this gets rid of testing though. Running integration tests are significantly more complicated to write and take longer to run. There is also race conditions present that you need to account for programmatically.. Such as waiting for a db to come up and schema to be applied. Or waiting for a specific event to occur in the daemon. That being said, this looks like a decent star…

I’ve never liked testing for logs, I’m not sure I see the point

Re: Testcontainers

#256

Earlier quoted context omitted.

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.

You can just run postgres natively: https://github.com/zonkyio/embedded-postgres-binaries + https://github.com/zonkyio/embedded-postgres or through WASM: https://github.com/electric-sql/pglite

Anyone have an opinion of embedded-postgres vs https://github.com/opentable/otj-pg-embedded (of which its a fork) for Clojure use?

Re: Testcontainers

#257
post #155

I dont understand how this is better than a docker-compose.yml with your dependencies, which plays nicer with all other tooling. Especially if there are complex dependencies between required containers it seems to be pretty weak in comparison. But i also only used it like 5 years ago, so maybe things are significantly better now.

One specific case that I encountered recently was implementing "integration" tests, where I needed to test some behavior that relies on the global state of a database. All other tests before were easily parallelized, and this meant our whole service could be fully tested within 10-30 seconds (dev machine vs. pipeline).

However, the new tests could not be run in parallel with the existing ones, as the changes in global state in the database caused flaky failures. I know there will be other tests like them in the future, so I want a robust way of writing these kinds of "global" tests without too much manual labor.

Spinning up a new postgres instance for each of these specific tests would be one solution.

I would like to instead go for running the tests inside of transactions, but that comes with its own sorts of issues.

Re: Testcontainers

#260
post #173

Earlier quoted context omitted.

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.

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 th…

Thank you taking the time to answer. Dagger looks cool, maybe I'll get the chance to use it in the future.
Post reply on HN