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

141–150 of 260 posts

Re: Testcontainers

#141

Post by theK »

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…

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.

Re: Testcontainers

#142

Post by dkdbejwi383 »

simonw wrote: post #117
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

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?

Re: Testcontainers

#143

Post by mk89 »

imiric wrote: post #135
CobrastanJorji wrote: post #89

Earlier quoted context omitted.

I love integration tests. You know why? Because I can safely refactor all I want! Unit tests are great, but if you significantly refactor how several classes talk to each other, and each of those classes had their own, isolated unit tests that mocked out all of the others, you're suddenly refactoring with no tests. But a black box integration tests? Refactor all your code, replace your databases, do whatever you want…

I've heard this aversion to unit tests a few times in my career, and I'm unable to make sense of it. Sure, integration tests "save" you from writing pesky unit tests, and changing them frequently after every refactor. But how do you quickly locate the reason that integration test failed? There could be hundreds of moving parts involved, and any one of them malfunctioning, or any unexpected interaction between them, c…

> 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 happy-path and maybe 1 or 2 negative scenarios, and that's it, missing out a bunch of potential regressions.

EDIT: This just to say that I don't believe the author of the comment said "don't write unit tests" (I hope not, at least!) but, if I can rephrase it, "well, the integration tests give you a better dopamine effect because they actually help you catch bugs". Which would be partially true also with properly written unit tests (and they would do so in a fraction of the time you need with integration tests).

Re: Testcontainers

#144

Post by orphea »

DanHulton wrote: post #98
mleo wrote: post #5

Earlier quoted context omitted.

It’s not coming across in your comment, but Testcontainers can work with unit tests to start a container, run the unit tests and shutdown. For example, to verify database operations against the actual database, the unit test can start an instance of Postgres run tests and then shut it down. If running tests in parallel, each test can start its own container and shutdown at the end.

Wouldn't that just massively, _massively_ slow down your tests, if each test was spinning up its own Postgres container? I ask because I really like this and would love to use it, but I'm concerned that that would add just an insane amount of overhead to the point where the convenience isn't worth the immense amount of extra time it would take.

A better approach is to spin up one container and a _template_ database before the tests. Apply migrations to that database. Then, each test creates its own database from the template, runs, and drops the database.

Tests can be run in parallel, and they are fast because the database is prepared just once, tests simply make a copy.

We're doing this in my company, I'm happy how it works.

Re: Testcontainers

#145

Post by ric2b »

imiric wrote: post #135
CobrastanJorji wrote: post #89

Earlier quoted context omitted.

I love integration tests. You know why? Because I can safely refactor all I want! Unit tests are great, but if you significantly refactor how several classes talk to each other, and each of those classes had their own, isolated unit tests that mocked out all of the others, you're suddenly refactoring with no tests. But a black box integration tests? Refactor all your code, replace your databases, do whatever you want…

I've heard this aversion to unit tests a few times in my career, and I'm unable to make sense of it. Sure, integration tests "save" you from writing pesky unit tests, and changing them frequently after every refactor. But how do you quickly locate the reason that integration test failed? There could be hundreds of moving parts involved, and any one of them malfunctioning, or any unexpected interaction between them, c…

If the test fails consistently (as it should) it is usually just a question of using a debugger and stepping through some suspect sections of the code to find the issue.

Compared to the amount of time saved by not rewriting unit tests every time you refactor stuff, it's a great trade-off.

Re: Testcontainers

#146

Post by razemio »

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…

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.

Re: Testcontainers

#147

Post by collyw »

perbu wrote: post #129
doctorpangloss wrote: post #125

Earlier quoted context omitted.

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.

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.

[flagged]

Re: Testcontainers

#148

Post by CodeNest »

doctorpangloss wrote: post #125
simonkagedal wrote: post #109

Earlier quoted context omitted.

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.

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.

It doesn't matter if it interfaces via CLI or not. Testcontainers tends to make things work but also introduces difficulty in resolution. You seem to have missed the point.

Re: Testcontainers

#149

Post by ric2b »

imiric wrote: post #139
fiznool wrote: post #132

Earlier quoted context omitted.

You might be interested in the ‘testing trophy’ as an alternative to the traditional pyramid. https://kentcdodds.com/blog/write-tests

This advice is so misguided that I'm concerned for our industry it's getting so much traction. > You really want to avoid testing implementation details because it doesn't give you very much confidence that your application is working and it slows you down when refactoring. You should very rarely have to change tests when you refactor code. Unit tests don't need to test implementation details. You could just as well…

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.

Re: Testcontainers

#150

Post by fuzzy2 »

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…

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.

Post reply on HN