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
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
- Use database transactions for isolation — Wrap each test in a transaction that rolls back after the test completes, ensuring clean state
- Create fresh state in each test — Use beforeEach to set up exactly the data each test needs. Never rely on state from other tests
- Use random ports — Start test servers on port 0 (OS assigns a random available port) to avoid conflicts
- Randomize test order — Configure your test runner to randomize test execution order to expose hidden dependencies
- Replace timeouts with polling — Instead of await sleep(1000), poll for the expected condition with a timeout: await waitFor(() => expect(result).toBe(expected))
- Use testcontainers — Spin up isolated database instances per test suite using Docker containers
Real developers can help you.
Omar Faruk
As a Product Engineer at Klasio, I contributed to end-to-end product development, focusing on scalability, performance, and user experience.
My work spanned building and refining core features, developing dynamic website templates, integrating secure and reliable payment gateways, and optimizing the overall system architecture.
I played a key role in creating a scalable and maintainable platform to support educators and learners globally.
I'm enthusiastic about embracing new challenges and making meaningful contributions.
Nam Tran
10 years as fullstack developer
Rudra Bhikadiya
I build and fix web apps across Next.js, Node.js, and DBs.
Comfortable jumping into messy code, broken APIs, and mysterious bugs.
If your project works in theory but not in reality, I help close that gap.
Dor Yaloz
SW engineer with 6+ years of experience,
I worked with React/Node/Python
did projects with React+Capacitor.js for ios
Supabase expert
legrab
I'll fill this later
PawelPloszaj
I'm fronted developer with 10+ years of experience with big projects. I have small backend background too
prajwalfullstack
Hi Im a full stack developer, a vibe coded MVP to Market ready product, I'm here to help
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 : )
Milan Surelia
Milan Surelia is a Mobile App Developer with 5+ years of experience crafting scalable, cross-platform apps at 7Span and Meticha. At 7Span, he engineers feature-rich Flutter apps with smooth performance and modern UI. As the Co-Founder of Meticha, he builds open-source tools and developer-focused products that solve real-world problems.
Expertise:
💡 Developing cross-platform apps using Flutter, Dart, and Jetpack Compose for Android, iOS, and Web.
🖋️ Sharing insights through technical writing, blogging, and open-source contributions.
🤝 Collaborating closely with designers, PMs, and developers to build seamless mobile experiences.
Notable Achievements:
🎯 Revamped the Vepaar app into Vepaar Store & CRM with a 2x performance boost and smoother UX.
🚀 Launched Compose101 — a Jetpack Compose starter kit to speed up Android development.
🌟 Open source contributions on Github & StackOverflow for Flutter & Dart
🎖️ Worked on improving app performance and user experience with smart solutions.
Milan is always happy to connect, work on new ideas, and explore the latest in technology.
Matthew Jordan
I've been working at a large software company named Kainos for 2 years, and mainly specialise in Platform Engineering. I regularly enjoy working on software products outside of work, and I'm a huge fan of game development using Unity. I personally enjoy Python & C# in my spare time, but I also specialise in multiple different platform-related technologies from my day job.
You don't need to be technical. Just describe what's wrong and a verified developer will handle the rest.
Get HelpFrequently 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.