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

161–170 of 260 posts

Re: Testcontainers

#161

Post by callamdelaney »

domano wrote: 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.

Because you may want to spin up a new postgres database to test a specific scenario in an automated way. Testcontainers allows you to do that from code, for example you could write a pytest fixture to provide a fresh database for each test.

Re: Testcontainers

#162

Post by piokoch »

hughesjj wrote: post #112
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…

Legit. Probably an unpopular opinion but if I had to chose only one type of test (queue a long discussion with no resolution over defining exact taxonomic boundaries), I'd go with integration over unit. Especially if you're a new contributor to a project. I think it comes down to exercising the flow between... Well, integrations across components. Even better? Take your integration test, put it on a cronjob in your V…

Right. Unit tests are typically a waste of time unless you have some complicated business logic (say, some insurance rates calculation, etc.).

This was advocated long time ago in the (great) book "Next Generation Java Testing: TestNG and Advanced Concepts" by Cédric Beust and Hani Suleiman (old people will remember his (in)famous The Bile Blog...).

Re: Testcontainers

#163

Post by mellutussa »

This is a very nice project, but it's awful that they're blurring the line of unit test and integration test. They are very different and both very important.

Things in the software world are very trendy. If this starts a trend of making people think that they're writing unit tests when they are writing integrations tests, we are fucked.

If I need to change code that you wrote I need a lightning fast way to figure out that I haven't broken your code according to the tests that you wrote. That's unit tests.

My changes might break the whole system. That's integration tests. I just to run that once and then I can go back to unit tests while I fix the mess I've made.

Re: Testcontainers

#164

Post by Aeolun »

ric2b wrote: post #149
imiric wrote: post #139

Earlier quoted context omitted.

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.

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.

Re: Testcontainers

#165

Post by imiric »

mk89 wrote: post #143
imiric wrote: post #135

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. 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 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 coverage are useless? That doesn't track at all.

I'd say that the answer is somewhere in the middle. If the company doesn't understand software development, it's the engineer's job to educate them, or find a better place to work at. It's also the engineer's job to educate lazy developers to care about testing and metrics like code coverage.

> if I can rephrase it, "well, the integration tests give you a better dopamine effect because they actually help you catch bugs"

And unit tests don't? I would argue that unit tests give you much more of that dopamine, since you see the failures and passes much more quickly, and there should be much more of them overall. Not that we should structure our work towards chasing dopamine hits...

I'd say that most of the people who advocate for this position haven't worked with a well tested codebase. Sadly, not all of us have the privilege of working with codebases like SQLite's, which go much beyond 100% line/statement coverage[1]. Is all that work in vain? Are they some crazy dogmatic programmers that like wasting their time? I would say: no. They just put a lot of effort and care in their product, which speaks for itself, and I would think makes working on it much safer, more efficient and pleasant.

I would also argue that the current state of our industry, and in turn everything that depends on software, where buggy software is the norm would be much better overall if that kind of effort and care would be put in all software projects.

[1]: https://www.sqlite.org/testing.html

Re: Testcontainers

#166

Post by Aeolun »

piokoch wrote: post #162
hughesjj wrote: post #112

Earlier quoted context omitted.

Legit. Probably an unpopular opinion but if I had to chose only one type of test (queue a long discussion with no resolution over defining exact taxonomic boundaries), I'd go with integration over unit. Especially if you're a new contributor to a project. I think it comes down to exercising the flow between... Well, integrations across components. Even better? Take your integration test, put it on a cronjob in your V…

Right. Unit tests are typically a waste of time unless you have some complicated business logic (say, some insurance rates calculation, etc.). This was advocated long time ago in the (great) book "Next Generation Java Testing: TestNG and Advanced Concepts" by Cédric Beust and Hani Suleiman (old people will remember his (in)famous The Bile Blog...).

Unit tests are fine for testing any kind of logic. Whether you consider the logic important is a different question.

Re: Testcontainers

#167

Post by silon42 »

circusfly wrote: post #84
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.

Agreed, this is the best way, testcontainers are over hyped.

Yeah, I prefer setting up docker-compose.yml myself, so I can startup services once, and also do manual testing.

The only thing I would maybe use testcontainers for is to deploy my own service into docker as part of integration test so I can test a more realistic deployment scenario instead of running it locally outside docker.

Re: Testcontainers

#168

Post by silon42 »

callamdelaney wrote: post #161
domano wrote: 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.

Because you may want to spin up a new postgres database to test a specific scenario in an automated way. Testcontainers allows you to do that from code, for example you could write a pytest fixture to provide a fresh database for each test.

If you need that, sure, but often this will be too expensive (heat my laptop too much).

Re: Testcontainers

#169

Post by TeeWEE »

AdrenalinMd wrote: post #127
TeeWEE wrote: post #99

Earlier quoted context omitted.

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…

It's not really a middle ground if you're not testing your service in the same conditions as in production environment. If you're not testing integration with Kafka, and the producer, your service is still lacking integration tests. Testing classes in isolation with testcontainer is fine. But I observed that with microservice architecture the line between E2E tests and integration tests are blurred. Microservices can…

True but if you want to test every merge-request it becomes expensive.

We had a customer k8s cluster per feature branch with e2e testing.

A middle ground is testcontainers for feature branches, and the trunk branch a full e2e suite deployed to a live cluster...

Re: Testcontainers

#170

Post by scns »

orphea wrote: post #144
DanHulton wrote: post #98

Earlier quoted context omitted.

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.

You can use one container for all tests.

https://java.testcontainers.org/test_framework_integration/m...

Post reply on HN