testland/testcontainers
Brings up real backing services (databases, message brokers, browsers, anything dockerizable) as throwaway containers from inside a test process - Java, Node.js, Python, Go, .NET, Ruby and ten other languages - using the Testcontainers library family. Wires the per-test container lifecycle, exposed-port → host-port mapping, wait strategies (port / log / HTTP / SQL), Ryuk-based cleanup, container-to-container networks, and the (experimental) `withReuse` shortcut for local dev. Use when integration tests need a real Postgres / Redis / Kafka / Selenium / etc. and the team wants per-test isolation without hand-rolled docker-compose teardown.
93
93%
Does it follow best practices?
Impact
—
Average score across 10 eval scenarios
Passed
No findings from the security scan
Evaluation results
Event tests sleep 25 seconds and still fail on a cold CI runner
Integration suite takes 11 minutes because the database starts 63 times
Integration tests fight over port 5432 on the build machine
Job fails on teardown with "network has active endpoints", and suites see each other's rows
One run in fifteen fails on the first query right after the database starts
Self-hosted runner filled up with leftover test containers
The API container cannot connect to the database the test just started
The billing container cannot call the stub server running inside the test JVM
Turning on parallel test methods made the integration suite fail at random
We switched on container keep-alive and every local run still starts from scratch
- Agent
- Claude Code
- Model
- Claude Sonnet 4.6