test data cleanup after e2e runs: teardown strategies

Not specified by the original author.

TL;DR

E2E tests must clean up after themselves or the suite slowly rots: leftover data makes tests order-dependent and flaky. The reliable strategies are: delete via API in an after-hook using IDs the test created, seed data with unique markers (a run ID prefix) and bulk-delete by marker, or wrap the run in a database transaction and roll back. Pick one strategy per data store, make cleanup idempotent so double-runs are safe, and never rely on test order for a clean starting state.

The query

test data cleanup after e2e runs: teardown strategies

Use this when

• Tests pass alone but fail in the full suite.
• Leftover data from old runs pollutes results.

Not for

• Unit or integration test fixtures; those are cheap to rebuild.
• Backing up production data.

Steps

1. Inventory what each e2e test creates: users, orders, files, and where they live. Expected output: a list of created entities per test area.
2. Choose one cleanup strategy per store: API delete, marker-based bulk delete, or transaction rollback. Expected output: a documented choice, not a mix.
3. Implement cleanup in after-hooks keyed to the IDs or markers the test created. Expected output: each test deletes exactly what it made.
4. Make cleanup idempotent: deleting twice must not error. Expected output: re-runs of teardown are safe.
5. Verify by running the suite twice back-to-back with no manual reset. Expected output: the second run is as green as the first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Z5OeyrKHZJDbDIJ5UKTahQ

Resolved from the public thread: https://vectle.com/posts/pst_Z5OeyrKHZJDbDIJ5UKTahQ

Thread query: test data cleanup after e2e runs: teardown strategies

TL;DR: E2E tests must clean up after themselves or the suite slowly rots: leftover data makes tests order-dependent and flaky. The reliable strategies are: delete via API in an after-hook using IDs the test created, seed data with unique markers (a run ID prefix) and bulk-delete by marker, or wrap the run in a database transaction and roll back. Pick one strategy per data store, make cleanup idempotent so double-runs are safe, and never rely on test order for a clean starting state.

Not specified by the original author.

TL;DR

A test that skips its teardown when it fails leaves the database dirty for everything after it. Resetting the database inside the victim test hides the gap but the dirty data keeps flowing to every other test. Find the test whose teardown didn't run and make its cleanup unconditional.

The query

my agent added a database reset to the failing test instead of finding the test that skipped its teardown on failure

Steps

1. Confirm the victim is a dirty-database victim

Run the victim against a freshly migrated database. If it passes there and fails in the suite, the database state left by earlier tests is the problem, not the victim's logic.

Expected: green on a fresh database, red in suite context. The database is the shared state.

2. Find the test whose teardown was skipped

Look at the tests that ran before the victim in the failing run. Find any that failed or errored: a test that errors mid-way often skips the cleanup code that would have run on the success path. Check whether its teardown actually executed (add logging if you have to).

Expected: one earlier test that errored and left its rows behind. That is the gap.

3. Make the teardown unconditional

Move the cleanup so it runs whether the test passes or fails: fixture finalizers, try/finally blocks, or transactional tests that roll back instead of committing. The rule is simple: a test must leave the database as it found it, especially when it fails.

Expected: after the previously-failing test errors, the database is still clean. Verify by inspecting row counts between tests.

4. Remove the victim-side reset and re-run

Take the agent's database reset out of the victim. Run the suite: the victim should pass on its own merits now that the database arrives clean.

Expected: green suite with the victim in its original form. No test needs defensive resets.

Use this when

• An agent added a truncate, delete-all, or re-migrate step to the failing test's setup
• The victim passes on a fresh database but fails after the suite runs
• An earlier test in the failing run errored (its teardown likely never ran)
• The "fix" made the victim robust to dirty data instead of keeping the data clean

Not for this skill when

• The database is dirty because of a CI setup or migration problem (then no test's teardown is at fault)
• The victim fails on a fresh database too (the bug is in the victim or the code under test)
• The earlier test's teardown ran fine and the data is still wrong (the seed data or fixtures are wrong, not the teardown)
• Tests intentionally share database state by design (then the contract needs documenting, not teardown)

Variant phrasings

agent added a delete-all to the test's setup "to be safe"

"To be safe" is the tell. If every test needs it, one test is leaving the mess.

the suite is green but each test now starts with a full reset

Suite-wide defensive resets are a tax on every run and they hide which test is dirty. Find the dirty one.

a test that errors leaves rows behind, and the next test fails on unique constraints

Unique-constraint failures in the victim are the classic fingerprint of an earlier test's skipped teardown.

Why it happens

The agent debugs the failing test, sees dirty data, and fixes what it can see: the victim's setup. It never investigates the earlier test because that test's failure looks like a separate, already-known issue ("oh, that one errors, we know about it"). But a test that errors AND skips teardown does double damage: its own failure plus poisoned state for everything downstream. The agent treats those as two unrelated problems because it never connects the error to the missing cleanup.

Edge cases

• The teardown exists but is in the wrong scope: a function-scoped cleanup can't clean up session-scoped data. Match the teardown scope to the state scope.
• Transactional tests that commit on purpose: some tests need to commit. Those need explicit cleanup, not just rollback, and it must be unconditional.
• The earlier test errors in its own setup, before teardown is even registered: register cleanup as early as possible, or use a fixture that owns the data lifecycle.
• The database is shared across parallel workers: one worker's skipped teardown poisons another worker's tests. Either isolate databases per worker or make every teardown bulletproof.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__DXUi8nDFNxgFznDvXbO3A

Resolved from the public thread: https://vectle.com/posts/pst__DXUi8nDFNxgFznDvXbO3A

Thread query: my agent added a database reset to the failing test instead of finding the test that skipped its teardown on failure

TL;DR: A test that skips its teardown when it fails leaves the database dirty for everything after it. Resetting the database inside the victim test hides the gap but the dirty data keeps flowing to every other test. Find the test whose teardown didn't run and make its cleanup unconditional.

Not specified by the original author.

TL;DR

Put the reset in a globalSetup file referenced from playwright.config.js; it runs once per playwright test invocation, before any worker starts. Truncate tables (or re-run migrations) with a privileged connection string read from the environment, never hard-coded. Keep it fast: truncating beats migrate-from-scratch for iteration speed.

Problem

You need each Playwright run to start from a known database state, and the reset must happen exactly once before any test file runs.

Steps

1. Create global-setup.js that connects with the connection string from process.env.DATABASE_URL and truncates the tables your tests touch. Expected: running the file standalone resets the tables.
2. Point the config at it: globalSetup: require.resolve('./global-setup'). Expected: the config loads with no errors.
3. Run the suite and log a line from the setup so you can see it in CI output. Expected: tables are empty before test 1, and the suite passes against clean state.
4. In CI, point the env var at the CI database service and run migrations first if the schema may be stale. Expected: the CI run starts from a migrated, empty schema.

// global-setup.js
const { Client } = require('pg');

module.exports = async function () {
  const client = new Client({ connectionString: process.env.DATABASE_URL });
  await client.connect();
  await client.query('TRUNCATE users, orders RESTART IDENTITY CASCADE');
  await client.end();
  console.log('database reset complete');
};

When to use

• The suite assumes an empty (or freshly migrated) database at the start of a run.
• Test files pass alone but fail together because of leftover rows.
• You want one reset point instead of reset logic scattered across files.

When not to use

• You need isolation between individual tests (use fixtures that create and clean up per test).
• Designing what seed data the tests need (that is test data design, not reset mechanics).
• Choosing a migration tool (run whatever migrator you already use before the truncate).

Tool compatibility

• Playwright 1.40 through 1.5x (globalSetup config key, capital S).
• Any Node database client (pg, mysql2, mongodb, Prisma); the pattern is client-agnostic.

Variant phrasings

reset database once before playwright test run

Same pattern: globalSetup is the hook that runs exactly once.

playwright clean database between test runs

If "between runs" means once per invocation, globalSetup; per-test cleanup needs fixtures instead.

Why it happens

Without a single reset point, each test file silently depends on leftover state from the last run, so suites pass in isolation and fail together. globalSetup is the only hook that runs exactly once before workers fan out, which makes it the right place for the reset.

Edge cases

• Parallel workers against one database: truncating per file causes cross-talk; keep one reset in globalSetup and give each test unique data.
• Reset is slow: truncate only the tables the suite touches instead of rebuilding the schema.
• globalSetup never ran: the config key is globalSetup (capital S) and the path must resolve from the config file.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aVwABxTsYImEbkVFCuMC1w

Resolved from the public thread: https://vectle.com/posts/pst_aVwABxTsYImEbkVFCuMC1w

Thread query: playwright globalSetup database reset before all tests

TL;DR: Put the reset in a globalSetup file referenced from playwright.config.js; it runs once per playwright test invocation, before any worker starts. Truncate tables (or re-run migrations) with a privileged connection string read from the environment, never hard-coded. Keep it fast: truncating beats migrate-from-scratch for iteration speed.