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

221–230 of 260 posts

Re: Testcontainers

#221

Post by jchw »

paxys wrote: post #208
jchw wrote: post #92

Earlier quoted context omitted.

> it really isn't worth it in the long term to take on a new external dependency for a bit of code that (1) is a critical part of the team's development and release process and (2) can be written in-house in maybe an hour. This seems to be quite a contradiction. If it's so easy to just write from scratch, then why would it be scary to depend on? Of course, it's not that easy to write from scratch. You could make a pr…

This thought process taken to the extreme is what results in half the internet depending on leftPad and isOdd to function. Open source is great, but there is a difference between providing a utility vs adding needless layers of abstraction. It is the responsibility of the developer to figure out which is which rather than reach for the package manager for every task in front of them. In this case, like I said earlier…

That's just a slippery slope argument. I am not arguing for people to depend on leftPad, I'm arguing that depending on a library like this which is probably tens of thousands of lines of tested code that does roughly what you want already is a damn good idea. Again, I don't want to handroll a solution and have to test it out across Windows, Mac, Linux and then check again to make sure it works with both Docker and Podman, and then again to check AArch64 Windows, AArch64 Mac and AArch64 Linux, and so on. I'd prefer to use a library. And hell, even if any of those things don't work, I can report it to the maintainers and possibly contribute a fix, and then everyone else gets to benefit too.

Re: Testcontainers

#222

Post by digger495 »

alright2565 wrote: post #196
piokoch wrote: post #160

Earlier quoted context omitted.

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

Pglite is not fully compatible and doesn't even support parameterized queries yet.

Re: Testcontainers

#223

Post by imiric »

mk89 wrote: post #191
imiric wrote: post #165

Earlier quoted context omitted.

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

I'm not sure if I understand your argument.

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

It's not different, just more thorough. Line and statement coverage are still useful metrics to track. They might not tell you whether you're testing all code paths, but they still tell you that you're at least testing some of them.

Very few projects take testing seriously to also track branch coverage, and even fewer go the extra mile of reaching 100% in that metric. SQLite is the only such project that does, AFAIK.

> 90-95% line coverage is exactly why many unit tests are garbage

Hard disagree. Line coverage is still a useful metric, and the only "garbage" unit tests are those that don't test the right thing. After all, you can technically cover a block of code, with the test not making the correct assertions. Or the test could make the right assertions, but it doesn't actually reproduce a scenario correctly. Etc. Coverage only tracks whether the SUT was executed, not if the test is correct or useful. That's the job of reviewers to point out.

> and why many come up with the argument "I prefer integration tests, unit tests are not that useful".

No. Programmers who say that either haven't worked on teams with a strong testing mindset, haven't worked on codebases with high quality unit tests, or are just being lazy. In any case, taking advice from such programmers about testing practices would not be wise.

Re: Testcontainers

#224

Post by whalesalad »

Integrated this in an afternoon. It was surprisingly simple and works great locally and also inside GitHub actions to do psql integration tests of our core app.

Re: Testcontainers

#225

Post by tomjakubowski »

cyptus wrote: post #113
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…

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

Do the whole test in a transaction and roll it back at the end.

Re: Testcontainers

#226

Post by alemanek »

thomasfromcdnjs wrote: post #47
alemanek wrote: post #21

Earlier quoted context omitted.

This is for integration tests.

Homepage hero says "Unit tests with real dependencies"

A unit test with real dependencies is by definition an integration test isn’t it?

I guess the unit in “Unit Test” is a bit subjective but every place I have worked we wrote both unit and integration tests that lived side by side. Integration tests used Test Containers and Unit Tests were isolated with mocks. So, only functional difference was the “unit” under test being more, or less, isolated.

Re: Testcontainers

#227

Post by xienze »

withinboredom wrote: post #211
xienze wrote: post #200

Earlier quoted context omitted.

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

yet people are showing up here and agreeing completely. So, it seems common enough not to need elaboration.

Counterpoint, I’m not the only person showing up in this thread saying “what exactly do you mean?” So I don’t think it’s clear what the OP is actually referring to. If you know, please enlighten us.

Re: Testcontainers

#228

Post by flakes »

hnben wrote: post #195
flakes wrote: post #134

Earlier quoted context omitted.

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?

It depends on what you’re testing. Applying the schema is pretty fast (30-40ms), compared to the container creation (1-2 seconds). If you need a lot of test data it would take time, but most of the time Im only applying enough rows to hit my test conditions. For crud apps I usually orchestrate the test setup using the public APIs of my application against the fresh instance.

Re: Testcontainers

#229

Post by Rapzid »

perfectspiral wrote: post #178
callamdelaney wrote: post #161

Earlier quoted context omitted.

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.

I don't know about Postgres but a MySQL container can take at least a few seconds to start up and report back as healthy on a Macbook Pro. You can just purge tables on the existing database in between tests, no need to start up a whole new database server each time.

You can also reuse containers with test containers.

Now the next question might be "Well why use test containers then if you are reusing containers".

Because you can express these dependencies and drive the config programmatically from your code and test harness.

Re: Testcontainers

#230

Post by jackcviers3 »

codeonline wrote: post #59
maxdaten wrote: post #29

Earlier quoted context omitted.

honest question: how are you writing integration tests? We are writing these as separate test suite often with the same test style. And in this scenario testcontainers are very valuable.

Why not use docker compose, bring up your infra in one container, your application in a second and your tests access it the application from a third.

Testcontainers can use docker-compose: https://java.testcontainers.org/modules/docker_compose/.

Really, you use testcontainers so that you can manage everything for your test with a single build command, instead of running something extra, then running your tests, then shutting down your docker containers. Plus, with it integrated into your test suites, you can run code against your docker containers on setup/teardown, before/after container start, before/after each test, etc.

Post reply on HN