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

191–200 of 260 posts

Re: Testcontainers

#191

Post by mk89 »

imiric wrote: post #165
mk89 wrote: post #143

Earlier quoted context omitted.

> I've heard this aversion to unit tests a few times in my career, and I'm unable to make sense of it. It's very simple: most of the time people are told by management that they MUST achieve a 80-90-95% of code coverage (with unit tests), which leads to a lot of absolutely worthless tests - tests for the sake of it. The irony is that the pieces that really count don't get tested properly, because you unit-test the ha…

> most of the time people are told by management that they MUST achieve a 80-90-95% of code coverage (with unit tests), which leads to a lot of absolutely worthless tests - tests for the sake of it So strict rules from management in a company that likely doesn't understand software development, and lazy developers who decide to ignore this by intentionally writing useless tests, lead to thinking that unit tests and c…

> Sadly, not all of us have the privilege of working with codebases like SQLite's, which go much beyond 100% line/statement coverage[1]...

Linked SQLite page mentions this:

> 100% branch test coverage in an as-deployed configuration

Branch test coverage is different from line coverage and in my opinion it should be the only metric used in this context for coverage.

90-95% line coverage is exactly why many unit tests are garbage and why many come up with the argument "I prefer integration tests, unit tests are not that useful".

Re: Testcontainers

#192

Post by simonw »

Aeolun wrote: post #164
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 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.

Re: Testcontainers

#193

Post by simonw »

dkdbejwi383 wrote: post #142
simonw wrote: post #117

Earlier quoted context omitted.

If I'm using Django I let Django's default test harness handle that for me - it runs each test in a transaction and rolls it back at the end of the test, which is pretty fast. https://docs.djangoproject.com/en/5.0/topics/testing/overvie... For my other projects I'm generally using SQLite where starting a new in-memory database is so fast it's effectively free.

How does that work when the system under test uses transactions itself?

A lot of databases these days support nested transactions using savepoints, which Django's test framework can take advantage of.

There's a separate mechanism for writing tests where you need to explicitly test transaction mechanics: https://docs.djangoproject.com/en/5.0/topics/testing/tools/#...

Re: Testcontainers

#194

Post by user_of_the_wek »

TeeWEE wrote: post #99
gui77aume wrote: post #77

Earlier quoted context omitted.

If you are testing a microservices "ball of mud", you can (and probably should) setup a testing environment and do your integration tests right there, against real dependencies. The tool seems nice for simple dependencies and local testing but I fail to see it as a game changer.

This is useful too but expensive. Test containers provide a middle ground. For example we have pure unit tests. But also some tests that boot up Postgres. Test the db migration and gives you a db to play with for your specific “unit” test test case. No need for a complete environment with Kafka etc. It provides a cost effective stepping stone to what you describe. What would be nice if test containers could create a…

In my last project we used https://java.testcontainers.org/modules/kafka/ to start a small Kafka container. It's not the exactly like a production installation, but it goes a long way.

Re: Testcontainers

#195

Post by hnben »

flakes wrote: post #134
cyptus wrote: post #113

Earlier quoted context omitted.

how do you handle resetting a sql database after every integration test? Testcontainers may help here by spinning up a new instance for every test but that seems very slow

I do this a lot for Postgres testing. In my setup, I create a single database for the entire test run. Each test creates its own schema in that database and applies the latest table definitions. With this setup, I only eat the container creation once, while allowing every test to operate in isolation from one another, be parallelized, and test against a real database. I do a similar trick for S3 containers by applyin…

doesn't it take a lot of time to create the schema and populate it with enough data to get going?

Re: Testcontainers

#196

Post by alright2565 »

piokoch wrote: post #160
fuzzy2 wrote: post #150

Earlier quoted context omitted.

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

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

Re: Testcontainers

#197

Post by withinboredom »

eecc wrote: post #153
choeger wrote: post #122

Earlier quoted context omitted.

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.

except the parent is wrong (at least the Java impl). see: https://github.com/testcontainers/testcontainers-java/blob/m... https://github.com/testcontainers/testcontainers-java/blob/m...

Their details might be wrong, but were perhaps not always wrong. Either way, the spirit of their argument is clearly not wrong.

Re: Testcontainers

#198

Post by et1337 »

Sammi wrote: post #175
et1337 wrote: post #80

I looked at testcontainers and ended up rolling my own version. One issue I had is that Docker is a very leaky abstraction. I needed to write one test and have it run in all these scenarios: - on a Mac - on a Linux VM - in a Docker container on a Linux VM, with a Docker socket mounted The networking for each of these is completely different. I had to make some opinionated choices to get code that could run in all cas…

"ended up rolling my own version" What does that mean in this case? What does a hand rolled version of this look like?

A golang library that uses the Docker SDK to create and run containers.

My version is more opinionated than testcontainers and can really only be used inside Go tests (relies on a testing.TB)

Re: Testcontainers

#199

Post by shepherdjerred »

supahfly_remix wrote: post #185

This looks pretty useful! Question on the nginx container. For my tests, this container is only useful when files are mounted into the container. For example, it needs an nginx.conf passed in. How do I do this with NginxContainer?

You can copy files into the container before it starts. Testcontainers provides APIs for this.

Re: Testcontainers

#200

Post by xienze »

withinboredom wrote: post #197
eecc wrote: post #153

Earlier quoted context omitted.

except the parent is wrong (at least the Java impl). see: https://github.com/testcontainers/testcontainers-java/blob/m... https://github.com/testcontainers/testcontainers-java/blob/m...

Their details might be wrong, but were perhaps not always wrong. Either way, the spirit of their argument is clearly not wrong.

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

Post reply on HN