171–180 of 260 posts
Earlier quoted context omitted.
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.
Because you don't have to muck around with docker-compose. I guess some people might find that more attractive.
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…
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.
I advocate for not having any integrated environment for automated testing at all. The aim should be to be able to run all tests locally and get a quicker feedback loop.
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.
Earlier quoted context omitted.
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 kuberne…
That reasoning seems more like one from policy/cargo cult rather than reasoning specific to your org. For something short lived and meant to be isolated I wouldn't want to subject them to even more infrastructural dependencies outside their control.
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…
What does that mean in this case? What does a hand rolled version of this look like?
Earlier quoted context omitted.
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]
If you say you're doing continuous deployment because you deploy every Tuesday evening, it's perfectly fair to point out that that's not continuous deployment.
Of course, you should follow it up by explaining why as well, but many companies don't actually follow the agile principles.
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.
Pulling up infra to run unit tests is an anti-pattern. This is a great tool for integration tests, though.
Testcontainers is awesome and all the hate it gets here is undeserved.
Custom shell scripts definitely can't compete.
For example one feature those don't have is "Ryuk": A container that testcontainers starts which monitors the lifetime of the parent application and stops all containers when the parent process exits.
It allows the application to define dependencies for development, testing, CI itself without needing to run some command to bring up docker compose beforehand manually.
One cool usecase for us is also having a ephemeral database container that is started in a Gradle build to generate jOOQ code from tables defined in a Liquibase schema.