{"slug": "testcontainers", "name": "Testcontainers", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 4, "commenters": 10, "warners": 1, "score": 4.062, "rising": 1.35, "first": "2025-12-04", "latest": "2026-09-26", "why": "testcontainers is great for ensuring multiple agents can run tests that don't conflict", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 4, "neutral": 5, "compare": 0, "warn": 1}, "spark": [0, 1, 0, 0, 0, 0, 0, 1, 0, 2, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "testcontainers is great for ensuring multiple agents can run tests that don't conflict", "kind": "", "icon": true, "domain": "testcontainers.com", "github_repo": null, "official_url": "https://testcontainers.com/", "pricing": "", "aliases": ["Testcontainers", "TestContainers"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 789854576, "item_id": 49365911, "url": "https://news.ycombinator.com/item?id=49365911", "by": "KronisLV", "date": "2026-08-19", "version": null, "stance": "recommend", "quote": "Testcontainers are great for tests in particular", "excerpt": "> Anyway, it is a basic practice of keeping test and dev environment as close as feasible to production, to avoid missing issues and wrong assumptions. Containers are great for this during development. Testcontainers are great for tests in particular when you don't want to use some mocked in-memory DB because those have the same issues as using a different DB during development: https://testcontainers.com/", "context": "", "use_case": "Containerized test dependencies", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789323091, "item_id": 49332693, "url": "https://news.ycombinator.com/item?id=49332693", "by": "CharlieDigital", "date": "2026-08-17", "version": null, "stance": "recommend", "quote": "Testcontainers[2] with automatic transactions to streamline and isolate integration tests", "excerpt": "This is a 5 part series that is intentionally (hand) written to help dev teams understand how to scaffold a codebase for agentic engineering by focusing on key, underlying technical decisions and manual wiring before building with AI. Getting the foundations right helps provide the tools and safeguards for coding agents to iterate more efficiently while reducing slop. Specifically: - Giving agents access to programma", "context": "", "use_case": "isolated integration tests", "switched_from": "", "story": "The Unexpected AI Stack: C# + .NET (Part 1)"}, {"id": 774904547, "item_id": 48431534, "url": "https://news.ycombinator.com/item?id=48431534", "by": "nimonian", "date": "2026-06-06", "version": null, "stance": "recommend", "quote": "testcontainers is great for ensuring multiple agents can run tests that don't conflict", "excerpt": "I do quite a lot of what this post describes in a reasonably large project. Here's what works for me: - write gherkin features for new features; update them for enhancements; don't touch them for refactors. Label your PRs with these nouns. - use pre-push hooks for type checks, linting, unit tests, and other quick, scriptable validations. - make a viteperess subsite in your repo, have the agents maintain it - document", "context": "works on a reasonably large project with agents", "use_case": "isolated parallel agent tests", "switched_from": "", "story": "Harness engineering: Leveraging Codex in an agent-first world"}, {"id": 742837425, "item_id": 46427339, "url": "https://news.ycombinator.com/item?id=46427339", "by": "jpalomaki", "date": "2025-12-29", "version": null, "stance": "recommend", "quote": "For some cases test-containers [1] is an option as well.", "excerpt": "Just docker compose and spin up 10 stacks? Should not be too much for modern laptop. But it would be great if tool like this could manage the ports (allocate unique set for each worktree, add those to .env) For some cases test-containers [1] is an option as well. I\u2019m using them for integration tests that need Postgres. [1] https://testcontainers.com/", "context": "", "use_case": "Integration tests with Postgres", "switched_from": "", "story": "Show HN: Superset \u2013 Terminal to run 10 parallel coding agents"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 759951296, "item_id": 47496956, "url": "https://news.ycombinator.com/item?id=47496956", "by": "mmarian", "date": "2026-03-23", "version": null, "stance": "warn", "quote": "advising people not to run this sort of stuff", "excerpt": "Wrote a blog post advising people not to run this sort of stuff last year: https://developerwithacat.com/blog/032025/test-containers-bad-idea/ It's just too much hassle to replicate cloud environments locally, just use unit tests and dev environments.", "context": "", "use_case": "running services in tests", "switched_from": "", "story": "Local Stack Archived their GitHub repo and requires an account to run"}]}], "who": [{"by": "nimonian", "context": "works on a reasonably large project with agents", "url": "https://news.ycombinator.com/item?id=48431534", "date": "2026-06-06"}], "tags": [], "use_cases": ["integration tests", "containerized test dependencies", "isolated integration tests", "isolated parallel agent tests", "running services in tests", "integration tests with postgres"], "compared": [{"slug": "postgresql", "name": "PostgreSQL", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=46414078", "title": "Stepping down as Mockito maintainer after 10 years", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49854416", "title": "Floci: Locally emulating any cloud service", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49361279", "title": "PostgreSQL for Everything", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49332692", "title": "The Unexpected AI Stack: C# + .NET (Part 1)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48416264", "title": "Harness engineering: Leveraging Codex in an agent-first world", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47493657", "title": "Local Stack Archived their GitHub repo and requires an account to run", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"neutral": 3, "recommend": 1}, "2026-01": {}, "2026-02": {"neutral": 1}, "2026-03": {"warn": 1}, "2026-04": {}, "2026-05": {}, "2026-06": {"recommend": 1}, "2026-07": {}, "2026-08": {"recommend": 2}, "2026-09": {"neutral": 1}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 797702337, "item_id": 49856396, "url": "https://news.ycombinator.com/item?id=49856396", "by": "microflash", "date": "2026-09-26", "version": null, "stance": "neutral", "quote": "run integration tests with Testcontainers [1]", "excerpt": "Been using it for a while to run integration tests with Testcontainers [1]. It's very good and much more lightweight than Localstack. [1]: https://testcontainers.com/", "context": "", "use_case": "integration tests", "switched_from": "", "story": "Floci: Locally emulating any cloud service"}, {"id": 789854576, "item_id": 49365911, "url": "https://news.ycombinator.com/item?id=49365911", "by": "KronisLV", "date": "2026-08-19", "version": null, "stance": "recommend", "quote": "Testcontainers are great for tests in particular", "excerpt": "> Anyway, it is a basic practice of keeping test and dev environment as close as feasible to production, to avoid missing issues and wrong assumptions. Containers are great for this during development. Testcontainers are great for tests in particular when you don't want to use some mocked in-memory DB because those have the same issues as using a different DB during development: https://testcontainers.com/", "context": "", "use_case": "Containerized test dependencies", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789323091, "item_id": 49332693, "url": "https://news.ycombinator.com/item?id=49332693", "by": "CharlieDigital", "date": "2026-08-17", "version": null, "stance": "recommend", "quote": "Testcontainers[2] with automatic transactions to streamline and isolate integration tests", "excerpt": "This is a 5 part series that is intentionally (hand) written to help dev teams understand how to scaffold a codebase for agentic engineering by focusing on key, underlying technical decisions and manual wiring before building with AI. Getting the foundations right helps provide the tools and safeguards for coding agents to iterate more efficiently while reducing slop. Specifically: - Giving agents access to programma", "context": "", "use_case": "isolated integration tests", "switched_from": "", "story": "The Unexpected AI Stack: C# + .NET (Part 1)"}, {"id": 774904547, "item_id": 48431534, "url": "https://news.ycombinator.com/item?id=48431534", "by": "nimonian", "date": "2026-06-06", "version": null, "stance": "recommend", "quote": "testcontainers is great for ensuring multiple agents can run tests that don't conflict", "excerpt": "I do quite a lot of what this post describes in a reasonably large project. Here's what works for me: - write gherkin features for new features; update them for enhancements; don't touch them for refactors. Label your PRs with these nouns. - use pre-push hooks for type checks, linting, unit tests, and other quick, scriptable validations. - make a viteperess subsite in your repo, have the agents maintain it - document", "context": "works on a reasonably large project with agents", "use_case": "isolated parallel agent tests", "switched_from": "", "story": "Harness engineering: Leveraging Codex in an agent-first world"}, {"id": 759951296, "item_id": 47496956, "url": "https://news.ycombinator.com/item?id=47496956", "by": "mmarian", "date": "2026-03-23", "version": null, "stance": "warn", "quote": "advising people not to run this sort of stuff", "excerpt": "Wrote a blog post advising people not to run this sort of stuff last year: https://developerwithacat.com/blog/032025/test-containers-bad-idea/ It's just too much hassle to replicate cloud environments locally, just use unit tests and dev environments.", "context": "", "use_case": "running services in tests", "switched_from": "", "story": "Local Stack Archived their GitHub repo and requires an account to run"}, {"id": 754497363, "item_id": 47156085, "url": "https://news.ycombinator.com/item?id=47156085", "by": "ashwindharne", "date": "2026-02-25", "version": null, "stance": "neutral", "quote": "It uses Testcontainers to start and autowire runtime deps", "excerpt": "Looks great -- always wished the admin panel came with more configurable bells and whistles. I've been exploring Quarkus recently (https://quarkus.io/), and it has a Dev UI with a similar extensible \"panels\" pattern. It's a bit different than Django since it's not for running in prod, but nonetheless it's pretty helpful. sort of a tangent, but quarkus also has a concept of \"dev services\" that are monitorable via the ", "context": "", "use_case": "", "switched_from": "", "story": "Show HN: Django Control Room \u2013 All Your Tools Inside the Django Admin"}, {"id": 742837425, "item_id": 46427339, "url": "https://news.ycombinator.com/item?id=46427339", "by": "jpalomaki", "date": "2025-12-29", "version": null, "stance": "recommend", "quote": "For some cases test-containers [1] is an option as well.", "excerpt": "Just docker compose and spin up 10 stacks? Should not be too much for modern laptop. But it would be great if tool like this could manage the ports (allocate unique set for each worktree, add those to .env) For some cases test-containers [1] is an option as well. I\u2019m using them for integration tests that need Postgres. [1] https://testcontainers.com/", "context": "", "use_case": "Integration tests with Postgres", "switched_from": "", "story": "Show HN: Superset \u2013 Terminal to run 10 parallel coding agents"}, {"id": 742673809, "item_id": 46417113, "url": "https://news.ycombinator.com/item?id=46417113", "by": "supriyo-biswas", "date": "2025-12-28", "version": null, "stance": "neutral", "quote": "", "excerpt": "You can use a library like [1] to mock out a real HTTP server with responses. [1] https://www.mock-server.com/", "context": "", "use_case": "", "switched_from": "", "story": "Stepping down as Mockito maintainer after 10 years"}, {"id": 742667680, "item_id": 46416730, "url": "https://news.ycombinator.com/item?id=46416730", "by": "sfn42", "date": "2025-12-28", "version": null, "stance": "neutral", "quote": "I use test containers and similar methods", "excerpt": "I use test containers and similar methods to test against a \"real\" db, but I also use mocks. For example to mock the response of a third party api, can't very well spin that up in a test container. Nother example is simply time stamps. Can't really test time related stuff without mocking a timestamp provider. It is a hassle a lot of the time, but I see it as a necessary evil.", "context": "", "use_case": "testing against real DB", "switched_from": "", "story": "Stepping down as Mockito maintainer after 10 years"}, {"id": 738385680, "item_id": 46149105, "url": "https://news.ycombinator.com/item?id=46149105", "by": "odie5533", "date": "2025-12-04", "version": null, "stance": "neutral", "quote": "For unit testing, I still use TestContainers which spins a full Postgres in Docker.", "excerpt": "For unit testing, I still use TestContainers which spins a full Postgres in Docker. But new alternatives like this make py-pglite (https://github.com/wey-gu/py-pglite) possible which is Python unit testing with PGlite. Even so, for Python unit testing I'm more confident in something like pgserver (https://github.com/orm011/pgserver) which offers the full, real Postgres in a lightweight pip package. Note: my take is s", "context": "", "use_case": "Integration testing with containers", "switched_from": "", "story": "PGlite \u2013 Embeddable Postgres"}]}