How can @Transactional tests create false confidence?

Finds failures hidden by test-owned transactions, automatic rollback, open persistence contexts, missing flushes, and separate server threads.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A Spring test marked @Transactional usually runs the test method in a transaction and rolls it back afterward. That makes cleanup easy, but unflushed writes may never reach constraints, and lazy associations can remain available because the persistence context stays open. Code can therefore pass in the test and fail when a production transaction commits or closes. I flush and clear when those boundaries are part of the behavior.

Full answer below

Practice focus

Test transactions, rollback isolation, flush timing, lazy loading, commit behavior, server boundaries, and honest cleanup.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
Rollback is convenient cleanup, but a test transaction can change the behavior it is supposed to observe.
A Spring test marked @Transactional usually runs the test method in a transaction and rolls it back afterward. That makes cleanup easy, but unflushed writes may never reach constraints, and lazy associations can remain available because the persistence context stays open. Code can therefore pass in the test and fail when a production transaction commits or closes. I flush and clear when those boundaries are part of the behavior.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A real HTTP server handles the request on another thread and in another transaction, so the test method's rollback does not undo server-side data. Transaction propagation and REQUIRES_NEW can also commit outside the expected rollback. I choose cleanup separately from the application behavior being tested: truncation, unique data, disposable schemas, or explicit cleanup may be more honest. Commit-time events and after-commit callbacks need a test that actually commits.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming rollback proves commit behavior.
Testing lazy loading only inside the test transaction.
Expecting client-side rollback to undo a RANDOM_PORT request.

How can @Transactional tests create false confidence?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue practice

Try a variant

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?