Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Testcontainers

testcontainers.com

Post reply on HN
Print view View original

241–250 of 260 posts

Re: Testcontainers

#241

Post by razemio »

btreecat wrote: post #236
razemio wrote: post #146

Earlier quoted context omitted.

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

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

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.

Re: Testcontainers

#242

Post by SOLAR_FIELDS »

razemio wrote: post #241
btreecat wrote: post #236

Earlier quoted context omitted.

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

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.

Re: Testcontainers

#243

Post by saghm »

dventimihasura wrote: post #234
perbu wrote: post #129

Earlier quoted context omitted.

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.

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

Re: Testcontainers

#244

Post by nym3r0s »

Something that improved developer experience by far and also sped up our builds is starting the container dependencies via docker-compose and connect to it for integration testing. This allows reuse of containers, you can connect to it after/during an integration test to debug without having to keep searching for ports constantly.

With TestContainers - I've perceived that running integration tests / a single test repeatedly locally is extremely slow as the containers are shut down when the java process is killed. This approach allows for this while also allowing to keep it consistent - example, just mount the migrations folder in the start volume of your DB container and you have a like-for-like schema of your prod DB ready for integration tests.

I've found the https://github.com/avast/gradle-docker-compose-plugin/ very useful for this.

Re: Testcontainers

#245

Post by btreecat »

razemio wrote: post #241
btreecat wrote: post #236

Earlier quoted context omitted.

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

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…

That's not a solution. This requires you to expose those host docker socket mounted into a guest container, which breaks some security mechanisms by preventing isolation from the host systems.

Which also does not work on k8s. It does work in docker compose, but also isn't portable to places where the docker socket isn't available, eg hosted pipelines.

Test containers seem to work well if you're not already properly using containers in your pipelines, and are not interested in deployment to k8s.

Re: Testcontainers

#246

Post by Aeolun »

simonw wrote: post #192
Aeolun wrote: post #164

Earlier quoted context omitted.

If I change something at the lowest level in my well abstracted system, only the unit tests for that component will fail, as the tests that ‘use’ that component mock the dependency. As long as the interface between components doesn’t change, you can refactor as much as you want.

I prefer having the freedom to change the interface between my components without then having to update large numbers of mocked tests.

Sure, that's a tradeoff that you make. Personally I update my implementations more often than I update the interfaces, so I'm happy to take that hit when modifying the interface in trade for knowing exactly where my implementations break.

Re: Testcontainers

#247

Post by Izkata »

imiric wrote: post #158
ric2b wrote: post #149

Earlier quoted context omitted.

If by "smallest pieces of the system" you mean something like individual classes then you are definitely testing implementation details. Whenever you change a method's parameters in one of those internal classes you'll have unit tests breaking, even though you're just refactoring code. Unit testing at the smallest piece level calcifies the codebase by making refactors much more costly.

> If by "smallest pieces of the system" you mean something like individual classes then you are definitely testing implementation details. No, there's nothing definite about that. The "unit" itself is a matter of perspective. Tests should be written from the perspective of the API user in case of the smallest units like classes and some integration tests, and from the perspective of the end user in case of E2E tests.…

Congrats, you understand what "unit test" was originally supposed to refer to. This is not what it's commonly meant to most people for years. The common meaning is "test every individual function in isolation".

I think this came about because of people copying the surface appearance of examples (syntactic units, functions) and not understanding what the example was trying to show (semantic units), then this simplification got repeated over and over until the original meaning was lost.

Re: Testcontainers

#249

Post by dustedcodes »

SOLAR_FIELDS wrote: post #88

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 it looks beautiful. And in a fair amount of use cases it can be really nice. But if you want it to play well with any other containerized workflow, good freaking luck. Testcontainers is the library that convinced me that shelling out to docker as an abstracti…

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

Re: Testcontainers

#250

Post by razemio »

btreecat wrote: post #245
razemio wrote: post #241

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…

That's not a solution. This requires you to expose those host docker socket mounted into a guest container, which breaks some security mechanisms by preventing isolation from the host systems. Which also does not work on k8s. It does work in docker compose, but also isn't portable to places where the docker socket isn't available, eg hosted pipelines. Test containers seem to work well if you're not already properly u…

Well for the environment you describe, there is no solution to this problem right? If you want to spawn test containers, you need a privileged container. At least I can not think of anyway to archive this without exposing the docker socket. You have to choose the right tooling for the right job.
Post reply on HN