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.

Jaime Orts-Caroff Jaime Orts-Caroff I'm a Senior Android developer, open to work in various fields Costea Adrian Costea Adrian Embedded Engineer specilizing in perception systems. Latest project was a adas camera calibration system. Jared Hasson Jared Hasson Full time lead founding dev at a cyber security saas startup, with 10 yoe and a bachelor's in CS. Building & debugging software products is what I've spent my time on for forever Bastien Labelle Bastien Labelle Full stack dev w/ 20+ years of experience Jacek Rozanski Jacek Rozanski Senior PHP/Symfony developer and DevOps engineer with 20+ years of professional experience, running opcode.pl (web development agency, est. 2004). Day job: I'm the sole backend developer at merketing company where I own and maintain 11 PHP/Symfony microservices on AWS (ECS Fargate, RDS, S3, CloudFront), handle the full CI/CD pipeline (Bitbucket Pipelines, Docker), and manage monitoring with Sentry and CloudWatch. These services handle high request volumes in production every month. What I bring to AI-built apps: - I audit and fix security issues (OWASP methodology), performance bottlenecks, and architectural problems in codebases generated by Cursor, Claude Code, Lovable, Bolt, and v0 - I refactor AI-generated prototypes into production-grade applications with proper error handling, testing, and clean architecture (SOLID, DDD, hexagonal architecture) - I set up the infrastructure AI tools don't touch: AWS hosting, CI/CD pipelines, automated deployments, database optimization, monitoring, and alerting - I integrate external services: payment providers, email systems, partner APIs, SSO/auth Tech stack: PHP 8.x, Symfony, React, Next.js, PostgreSQL, MySQL, Docker, AWS (ECS, RDS, S3, SQS/SNS, CloudFront), Terraform, Supabase. I also use AI tools daily (Claude Code, Cursor) in my own workflow, so I understand both the strengths and the gaps in AI-generated code. Based in Poland (CET timezone). Available for async work and calls during EU/US business hours. Yovel Cohen Yovel Cohen I got a lot of experience in building Long-horizon AI Agents in production, Backend apps that scale to millions of users and frontend knowledge as well. prajwalfullstack prajwalfullstack Hi Im a full stack developer, a vibe coded MVP to Market ready product, I'm here to help Matt Butler Matt Butler Software Engineer @ AWS 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. hanson1014 hanson1014 Full-stack developer experienced in fixing and deploying AI-generated apps from Lovable, Bolt.new, Cursor, and Replit. I specialize in debugging Supabase integration issues (auth flows, RLS policies, database connections), fixing broken deployments, resolving routing/blank screen problems, and cleaning up messy React/Vite codebases. I also build production apps with the Claude API and have shipped a Mac desktop dev tool (Nexterm from scratch. Based in Hong Kong, fast turnaround.

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