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

41–50 of 260 posts

Re: Testcontainers

#41

Post by gv83 »

simonw wrote: post #25

I was intrigued to see that they have PyPI packages for a ton of different things - like https://pypi.org/project/testcontainers-postgres That wheel file is only 2.9KB, so I grabbed a copy to see how it works. I've put the contents in a Gist here: https://gist.github.com/simonw/c53f80a525d573533a730f5f28858... It's pretty neat - it depends on testcontainers-core, sqlalchemy and psycopg2-binary and then defines a Post…

This is also its downfall as my organization uses asyncpg and compatibility with it is still absent iirc :(

Re: Testcontainers

#43

Post by sverhagen »

ants_everywhere wrote: post #33

> No more need for mocks or complicated environment configurations. Define your test dependencies as code, then simply run your tests and containers will be created and then deleted. Wait what? They think you don't need unit tests because you can run integration tests with containers? It's trivial to set up a docker container with one of your dependencies, but starting containers is painful and slow.

1) At least in the Java world, the term "unit testing" is often confused by "things you do in JUnit", which runs both "pure" unit tests and project-level integration tests, i.e. spinning up an application context (like Spring) and testing against real REST endpoints etc.

2) While unit tests are cheaper and quicker than (project-level) integration tests, they also in many cases don't provide results as good a result and level of confidence, because a lot of run-time aspects (serialization, HTTP responses, database responses, etc.) are not as straightforward to mock. There's been some noise about The Testing Trophy, instead of the Testing Pyramid where, in short, there are still unit tests where it makes sense, but a lot of testing has moved to the (project-level) integration tests. These are slower, but only by so much that the trade-off is often worth it. Whether it's worth it, depends heavily on what you're testing. If it's a CRUD API: I use integration tests. If it's something algorithmic, or string manipulation, etc.: I use unit tests.

When I saw the Testing Trophy presented, it came with the asterisk that (project-level) integration testing has gotten easier and cheaper over time, thus allowing a shift in trade-off. Testcontainers is one of the primary reasons why this shift has happened. (And... I respect that it's not for everyone.)

Some references: https://kentcdodds.com/blog/the-testing-trophy-and-testing-c... https://www.youtube.com/watch?v=t-HmXomntCA

Re: Testcontainers

#44

Post by ants_everywhere »

tomnipotent wrote: post #36
ants_everywhere wrote: post #33

> No more need for mocks or complicated environment configurations. Define your test dependencies as code, then simply run your tests and containers will be created and then deleted. Wait what? They think you don't need unit tests because you can run integration tests with containers? It's trivial to set up a docker container with one of your dependencies, but starting containers is painful and slow.

No mocks doesn't mean no tests. It means running tests against the full code path which includes requests to running instances of the services you might otherwise mock. For many apps and use cases, the overhead in managing container state is worth it.

> It means running tests against the full code path which includes requests to running instances of the services you might otherwise mock.

Yeah, those are called end to end tests and you run them after integration tests which you run after unit tests. It sounds to me like they're saying just skip to the end to end tests.

> For many apps and use cases, the overhead in managing container state is worth it.

Yeah, and typically you'd run them after you run unit and integration tests. If I have 10 libraries to test that have database access, I have to run 10 database containers simultaneously every few minutes as part of the development process? That's overkill.

Re: Testcontainers

#45

Post by weq »

dm03514 wrote: post #17

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

Can you explain more in more detail why this is a game changer if i already have an inhouse framework that is similiar in using docker for integration tests? Does it start docker up faster then you could do normally? Is it just the out of the box apis it provides?

I dont know why integration testing like this is considered a gamechanger. the testing pyramid is a testing pyramid for a reason and its always considered them important. Sometimes starting with integration tests in your project is right because your dont waste time doing manual point and clicks. Instead you design your system around being able to integration test, this includes when you choose dependancies. You think to yourself "how easily will that be able to be stood up on its own from a command?" If the answer is "not very good" then you move on.

Re: Testcontainers

#46

Post by mrAssHat »

marginalia_nu wrote: post #35
mrAssHat wrote: post #27

Testcontainers aren't even compatible with kubernetes, that's a tool from the past.

Why'd you run them in kubernetes? Seems like extreme overkill for launching a short lived container for an integration test. What could kubernetes possibly add to that?

Because we are a big company and would like to utilize resources better.

We also want homogeneity in tech when possible (we already heavily use kubernetes, we don't want to keep docker hosts anymore).

Teams of testers need to be accounted in terms of resource quotas and RBAC.

What exactly do you see as an overkill in wanting to run short-lived containers in kubernetes rather than in docker (if we already have kubernetes and "cook" it ourselves)?

Re: Testcontainers

#48

Post by paxys »

I read through the docs and am still confused about what this actually does beyond running a single docker run command in the background and returning control to your code when the container is up.

Re: Testcontainers

#49

Post by sverhagen »

weq wrote: post #45
dm03514 wrote: post #17

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

Can you explain more in more detail why this is a game changer if i already have an inhouse framework that is similiar in using docker for integration tests? Does it start docker up faster then you could do normally? Is it just the out of the box apis it provides? I dont know why integration testing like this is considered a gamechanger. the testing pyramid is a testing pyramid for a reason and its always considered…

If you have an existing in-house framework for anything, maybe it's not worth switching over. It does help though when a best practice bubbles to the top and makes this in reach for those who don't have an existing in-house framework and who wouldn't know how to get started on one. It also helps for more people to have a shared understanding about a subject like this thanks to a popular implementation.

Meanwhile, Testcontainers is done quite well. It's not perfect, but it's sure better than the in-house stuff I built in the past (for the same basic concept).

No, it does not start faster than other Docker containers.

I do challenge the testing pyramid, though. At the risk of repeating my other comment on a different branch of the discussion: the value of integration tests is high, as the cost of integration tests has decreased, it makes sense to do more integration testing, at the expense of unit testing. The cost has decreased exactly due to Docker and mature application frameworks (like in Java: Spring). (See: Testing Trophy.)

Re: Testcontainers

#50

Post by paxys »

dm03514 wrote: post #17

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

FYI Docker already has a RESTful API, and programming container start/stop is trivial to do in any language. I haven't used Testcontainers before, and can kinda see the utility, but IMO 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.
Post reply on HN