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

11–20 of 260 posts

Re: Testcontainers

#11

Post by cosmosgenius »

redact207 wrote: post #2

I didn't quite understand why this was made. We create our local test environments using docker-compose, and so I read: > Creating reliable and fully-initialized service dependencies using raw Docker commands or using Docker Compose requires good knowledge of Docker internals and how to best run specific technologies in a container This sounds like a abstraction over docker-compose, which lets you define your docker…

I just started using them specifically to test docker container implementation (Correctness of Dockerfile, entrypoint etc.)

Re: Testcontainers

#12

Post by NomDePlum »

dns_snek wrote: post #6
marginalia_nu wrote: post #4

Earlier quoted context omitted.

Testcontainers are for testing individual components, apart from the application. I built a new service registry recently, its unit tests spins up a zookeeper instance for the duration of the test, and then kills it. Also very nice with databases. Spin up a clean db, run migrations, then test db code with zero worries about accidentally leaving stuff in a table that poisons other tests. I guess the killer feature is…

> Also very nice with databases. Spin up a clean db, run migrations, then test db code with zero worries about accidentally leaving stuff in a table that poisons other tests. Are you spinning up a new instance between every test case? Because that sounds painfully slow. I would just define a function which DELETEs all the data and call it between every test.

It supports both patterns (and variations in between). So you get to pick between isolation at a test level or if you want less overhead, rolling back the commit or other ways to cleanup.

Can only speak for the Golang version of the lib, but spinning up new instances was surprisingly quick.

Re: Testcontainers

#17

Post by dm03514 »

Test containers is such a game changer for integration testing, they have language specific docker apis that make it trivial to bring up containers and verify that they are fully initialized and ready to accept connections.

Pretty much every project I create now has testcontainers for integration testing :)

I setup CI so it lints, builds, unit tests then integration tests (using testcontainers)

https://github.com/turbolytics/latte/blob/main/.github/workf...

Their language bindings provide nice helper functions for common database operations (like generating a connection uri from a container user)

https://github.com/turbolytics/latte/blob/main/internal/sour...

I use them in $day job use them in side projects use them everywhere :)

Re: Testcontainers

#18

Post by nomel »

devthane wrote: post #16
marginalia_nu wrote: post #13

Earlier quoted context omitted.

What if you are unit testing something that is dependent on infra?

Typically you mock them in unit tests.

I've rarely found this to be worth it, for the effort required for a proper mock, in a complex system. I've seen most people mock in ways that are so superficial that it's basically a no-op.

Re: Testcontainers

#19

Post by marginalia_nu »

devthane wrote: post #16
marginalia_nu wrote: post #13

Earlier quoted context omitted.

What if you are unit testing something that is dependent on infra?

Typically you mock them in unit tests.

Seems like such a test would be strictly less useful than a test that runs against the real dependeny.
Post reply on HN