Windsurf testing

Test Database Not Resetting Between Tests in Windsurf Project

Tests in your Windsurf-generated project fail intermittently because the database retains data from previous test runs. Tests that pass individually fail when run together, test order matters, and adding a new test breaks existing ones. The test suite is unreliable and developers lose confidence in the results.

Cascade generates tests that create database records but doesn't clean them up afterward. Test A inserts a user, Test B expects an empty users table, and Test B fails because Test A's user is still there. The problem gets worse as more tests are added, creating an increasingly tangled web of data dependencies.

The failures are often non-deterministic — they depend on which tests run first, whether a previous test run completed fully, and sometimes even on timing. This makes them extremely hard to debug.

Error Messages You Might See

Expected 1 row but found 5 Error: duplicate key value violates unique constraint Test passed individually but fails in suite Error: relation has dependent rows - cannot truncate Expected empty array but received [previous test data]
Expected 1 row but found 5Error: duplicate key value violates unique constraintTest passed individually but fails in suiteError: relation has dependent rows - cannot truncateExpected empty array but received [previous test data]

Common Causes

  • No afterEach cleanup — Tests create database records but don't have afterEach hooks to clean up created data
  • Shared database between test runs — Tests use the development database instead of a dedicated test database that gets reset
  • No transaction rollback — Tests don't wrap operations in transactions that get rolled back, so changes persist
  • Truncation order wrong — Tables with foreign keys must be truncated in the correct order, or truncation fails silently
  • Seed data conflicts — Database seeds run before tests and create data with fixed IDs that conflict with test-created records
  • Parallel tests sharing state — Tests running in parallel write to the same tables and interfere with each other

How to Fix It

  1. Use transactions with rollback — Wrap each test in a database transaction and roll it back in afterEach. This is the fastest and cleanest approach
  2. Add truncation in beforeEach — Truncate all tables before each test with TRUNCATE TABLE ... CASCADE (PostgreSQL) or DELETE FROM (SQLite)
  3. Use a dedicated test database — Configure a separate database for tests in .env.test. Never run tests against your development or production database
  4. Install a test cleanup library — Use libraries like pg-mem (in-memory PostgreSQL), or prisma's test utils that handle cleanup automatically
  5. Isolate parallel tests — If running tests in parallel, use separate schemas or databases per worker to prevent interference
  6. Reset sequences and IDs — After truncation, reset auto-increment sequences so tests don't depend on specific ID values

Real developers can help you.

prajwalfullstack prajwalfullstack Hi Im a full stack developer, a vibe coded MVP to Market ready product, I'm here to help 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 Rudra Bhikadiya 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. Meïr Ankri Meïr Ankri Full-stack developer specializing in React / Next.js / Node.js with 6+ years of experience. I've worked across various sectors including automotive (Reezocar/Société Générale), healthcare (Medical Link SaaS), and e-commerce (Glasman). I build web apps end-to-end, from architecture to production, with a focus on scalability, performance, and code quality. I also mentor junior developers and contribute to technical decisions and code reviews. David Olverson David Olverson Solo dev shipping production apps with AI-assisted development. I specialize in rescuing broken Lovable/Bolt/Cursor builds and taking them to production. 10+ apps shipped including SaaS CRMs, gaming platforms, real estate tools, and Discord bots. Stack: Next.js 16, TypeScript, Tailwind CSS, FastAPI, PostgreSQL, Prisma. I use Claude Code with 50+ custom skills for rapid delivery. Average turnaround: 2-4 weeks from broken prototype to production. 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. Anthony Akpan Anthony Akpan Developer with 8 years of experience building softwares fro startups 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. BurnHavoc BurnHavoc Been around fixing other peoples code for 20 years. 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.

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

Should I use truncation or transaction rollback for test cleanup?

Transaction rollback is faster and cleaner — each test runs in a transaction that gets rolled back, leaving no trace. However, it doesn't work if your code commits transactions internally. Truncation is simpler but slower because it actually deletes and recreates data.

Why do my tests pass individually but fail together?

This is a classic sign of missing test isolation. One test creates data that another test doesn't expect. Add cleanup (truncation or rollback) in beforeEach or afterEach hooks so each test starts with a known database state.

Related Windsurf 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