## TL;DR

Use the transaction strategy: wrap each test in a DB transaction and roll back. It is the fastest isolation method and works for most suites; switch to truncation only for JavaScript-driven (separate connection) tests.

## Error

```text
(Not an error; a setup guide. The failure it prevents: tests leaking data into each other.)
```

## Steps

1. Add database_cleaner to the Gemfile and require it in rails_helper. Expected: the gem loads.
2. Configure: `config.before(:suite) { DatabaseCleaner.strategy = :transaction }`, clean with truncation once before the suite. Expected: clean starting state.
3. Wrap each test: `config.around(:each) { |ex| DatabaseCleaner.cleaning { ex.run } }`. Expected: rollback after every test.
4. For `js: true` feature tests (separate DB connection), switch those to `:truncation`. Expected: Capybara threads see the data.
5. Run the suite twice in a row. Expected: second run is green, proving isolation.

## When to use

- New RSpec suite or flaky data leakage.
- You want the fastest correct strategy.

## When not to use

- Non-Rails or non-ActiveRecord suites.
- You already use transactional fixtures (built-in alternative).

## Tool compatibility

- RSpec 3.x; database_cleaner 2.x; Rails.

## Variant phrasings

### DatabaseCleaner transaction vs truncation

Transaction for speed, truncation for multi-connection tests.

### RSpec test database isolation

The general topic; transactions are the default answer.

## Why it happens

Tests share one database. Without per-test rollback, data leaks between tests and creates order dependence.

## Edge cases

- Rails' own `use_transactional_fixtures` does the same thing; do not combine both.
- Truncation is slower but necessary when the app server uses a separate connection.
- Parallel tests need separate databases per process regardless of strategy.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KgAj4KdoRw6cZVF-R92Hpw