Claude Code testing

Integration Tests Fail Randomly Due to Shared State

Your integration tests pass when run individually but fail randomly when run as a suite. The failures are non-deterministic: different tests fail on different runs, tests that were passing start failing after adding new tests, and the CI pipeline has become unreliable with intermittent failures.

Flaky tests are a serious productivity drain. Developers lose trust in the test suite, start ignoring failures ('it's just a flaky test'), and eventually stop running tests altogether. Real bugs hide behind the noise of flaky failures.

Claude Code generates integration tests that work in isolation but share database state, use hardcoded ports, rely on test ordering, or have timing dependencies that cause failures when tests run in parallel or in different orders.

Error Messages You Might See

Error: listen EADDRINUSE :::3000 Expected 1 row but found 3 rows Timeout: Async callback was not invoked within 5000ms Error: relation 'users' already exists 1 test passed, 1 test failed (different test each run)
Error: listen EADDRINUSE :::3000Expected 1 row but found 3 rowsTimeout: Async callback was not invoked within 5000msError: relation 'users' already exists1 test passed, 1 test failed (different test each run)

Common Causes

  • Shared database state between tests — One test creates data that another test doesn't expect, or a test deletes data another test needs
  • No database cleanup between tests — Tests don't reset the database to a known state before or after running
  • Hardcoded ports — Multiple test files try to start servers on the same port, causing EADDRINUSE errors
  • Test order dependency — Tests rely on being run in a specific order because earlier tests set up state that later tests need
  • Timing-dependent assertions — Tests use setTimeout or fixed delays that are long enough locally but too short in CI

How to Fix It

  1. Use database transactions for isolation — Wrap each test in a transaction that rolls back after the test completes, ensuring clean state
  2. Create fresh state in each test — Use beforeEach to set up exactly the data each test needs. Never rely on state from other tests
  3. Use random ports — Start test servers on port 0 (OS assigns a random available port) to avoid conflicts
  4. Randomize test order — Configure your test runner to randomize test execution order to expose hidden dependencies
  5. Replace timeouts with polling — Instead of await sleep(1000), poll for the expected condition with a timeout: await waitFor(() => expect(result).toBe(expected))
  6. Use testcontainers — Spin up isolated database instances per test suite using Docker containers

Real developers can help you.

rayush33 rayush33 JavaScript (React.js, React Native, Node.js) Developer with demonstrated industry experience of 4+ years, actively looking for opportunities to hone my skills as well as help small-scale business owners with solutions to technical problems Alvin Voo Alvin Voo I’ve watched the tech landscape evolve over the last decade—from the structured days of Java Server Pages to the current "wild west" of Agentic-driven development. While AI can "vibe" a frontend into existence, I specialize in the architecture that keeps it from collapsing. My expertise lies in the critical backend infrastructure: the parts that must be fast, secure, and scalable. I thrive on high-pressure environments, such as when I had only three weeks to architect and launch an Ethereum redemption system with minimal prior crypto knowledge, turning it into a major revenue stream. What I bring to your project: Forensic Debugging: I don't just "patch" bugs; I use tools like Datadog and Explain Analyzers to map out bottlenecks and resolve root causes—like significantly reducing memory usage by optimizing complex DB joins. Full-Stack Context: Deep experience in Node.js and React, ensuring backends play perfectly with mobile and web teams. Sanity in the Age of AI: I bridge the gap between "best practices" and modern speed, ensuring your project isn't just built fast, but built to last. Jaime Orts-Caroff Jaime Orts-Caroff I'm a Senior Android developer, open to work in various fields Krishna Sai Kuncha Krishna Sai Kuncha Experienced Professional Full stack Developer with 8+ years of experience across react, python, js, ts, golang and react-native. Developed inhouse websearch tooling for AI before websearch was solved : ) Richard McSorley Richard McSorley Full-Stack Software Engineer with 8+ years building high-performance applications for enterprise clients. Shipped production systems at Walmart (4,000+ stores), Cigna (20M+ users), and Arkansas Blue Cross. 5 patents in retail/supply chain tech. Currently focused on AI integrations, automation tools, and TypeScript-first architectures. Matthew Butler Matthew Butler Systems Development Engineer @ Amazon Web Services Stanislav Prigodich Stanislav Prigodich 15+ years building iOS and web apps at startups and enterprise companies. I want to use that experience to help builders ship real products - when something breaks, I'm here to fix it. zipking zipking I am a technologist and product builder dedicated to creating high-impact solutions at the intersection of AI and specialized markets. Currently, I am focused on PropScan (EstateGuard), an AI-driven SaaS platform tailored for the Japanese real estate industry, and exploring the potential of Archify. As an INFJ-T, I approach development with a "systems-thinking" mindset—balancing technical precision with a deep understanding of user needs. I particularly enjoy the challenge of architecting Vertical AI SaaS and optimizing Small Language Models (SLMs) to solve specific, real-world business problems. Whether I'm in a CTO-level leadership role or hands-on with the code, I thrive on building tools that turn complex data into actionable value. legrab legrab I'll fill this later Vlad Temian Vlad Temian 15+ years shipping production infrastructure for startups. Former CTO at qed.builders (acquired by The Sandbox). Cursor ambassador and agentic tooling builder. I've scaled systems, automated deployments, and built observability tools for AI coding workflows. I specialize in taking vibe-coded apps from broken prototype to production-ready: fixing Supabase auth/RLS, Stripe integrations, deployment pipelines, and cleaning up AI-generated spaghetti. I build tools in this space (agentprobe, claudebin, micode) and understand both sides: how AI generates code and why it breaks. https://blog.vtemian.com/

You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.

Get Help

Frequently Asked Questions

How do I isolate database state between integration tests?

The best approach is to wrap each test in a database transaction and roll it back after the test. Alternatively, use TRUNCATE on all tables in beforeEach, or use testcontainers to spin up a fresh database per test suite.

Why do my tests pass locally but fail in CI?

CI environments are typically slower and have less CPU. Timing-dependent tests that pass locally may timeout in CI. Replace fixed delays with polling/waitFor patterns and increase timeouts for CI environments.

Related Claude Code Issues

Can't fix it yourself?
Real developers can help.

You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.

Get Help