Re:Testcontainers
by maxdaten on Tuesday February 27, 2024 @07:47PM
(#39532432)
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.
[ Parent
| on HN ]
Re:Testcontainers
by codeonline on Tuesday February 27, 2024 @09:17PM
(#39533102)
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.
Meanwhile docker compose selling point: 'because you don't have to muck around with testcontainers; I guess some people might find that more attractive'.
Oh, absolutely! And as the other guy pointed out, docker-compose can be quite reusable when developing locally if you write it right.
But at $WORKPLACE we often use pytest-xprocess to start the required app in the same container where the tests run. It's probably the easiest way mostly because a custom wrapper does all the heavy lifting (starts the app, checks that it is running and responding to requests before the tests start, correctly terminates it when tests end).
You'd probably need it for the development environment anyway so you might as well reuse it
Re:Testcontainers
by jackcviers3 on Wednesday February 28, 2024 @01:41PM
(#39542012)
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.