How do Spring's test-specific transaction semantics (@Transactional on tests) affect test isolation?

Database-backed integration tests face a classic isolation problem: if Test A inserts a row and it stays committed, Test B (or a later run of Test A itself) might see stale or conflicting data, unless every test carefully cleans up after itself.

Spring's test framework addresses this directly: annotating a test method or class with @Transactional wraps that test in a real database transaction that is, by default, automatically rolled back once the test completes — regardless of whether the test's own code ever explicitly commits, and regardless of whether the test passed or failed:

@SpringBootTest
@Transactional // every test method below runs in its own transaction, rolled back afterward
class OrderRepositoryTest {

    @Autowired OrderRepository orderRepository;

    @Test
    void savingAnOrderMakesItFindable() {
        Order saved = orderRepository.save(new Order(...));
        assertThat(orderRepository.findById(saved.getId())).isPresent();
        // no cleanup code needed — this insert is rolled back automatically after the test method returns
    }

    @Test
    void countIsUnaffectedByPreviousTest() {
        // starts from a clean slate — the previous test's insert never actually persisted
        assertThat(orderRepository.count()).isEqualTo(0);
    }
}

Why this matters for isolation: each @Test method gets its own transaction (started before the test, rolled back after), so tests never leak state into one another through the database — no manual DELETE FROM orders cleanup code, no ordering dependency between tests, and no risk of one test's leftover data silently breaking an unrelated test run later.

Important limitation to be aware of: this specifically tests behavior as observed from within a single transaction — it doesn't verify what actually happens once a transaction genuinely commits (e.g., whether a database trigger, a separate connection's read, or an actual cross-transaction concurrency scenario behaves correctly), since the rollback means nothing is ever really committed at all. For a test that specifically needs to verify true commit/cross-transaction behavior, you'd need to explicitly avoid the auto-rollback (e.g., via @Commit, used sparingly) or structure the test to genuinely span separate transactions.

Also worth noting: this rollback-based isolation happens at the database transaction level — it has no bearing on isolating things like static/shared in-memory state, external HTTP calls to third-party services, or message broker interactions, which need their own isolation strategy (mocking, Testcontainers with cleanup, etc.) regardless of @Transactional on the test.