A green @DataJpaTest can prove only that Hibernate handed back the same object

The prescription has two steps and only the second one does the work that the test name promises. Flushing pushes the write-behind queue at the database, which is the moment a strict column constraint finally gets consulted ^[10]. But a flushed entity is still managed and still sitting in the identity map, so the next findById is still answered from memory ^[1][2]. Clearing the persistence context is the step that forces a fresh entity graph to be hydrated from rows ^[16].

Look at what the sample assertions can actually fail on. The test checks that the loaded object is not null and that its name is "Gaming Laptop" ^[6]. Both of those are properties of the Java object the test constructed a line earlier, and that object is what find() returns ^[2][5]. The pass signal is decoupled from the database contents ^[15].

The author is careful about the blast radius, and that carefulness is the useful part. Custom JPQL and native @Query methods issue real SQL whether or not the entity is managed, so those tests do reach the dialect ^[7]. The exposure is confined to the find() path, which is also the path a CRUD suite leans on hardest, because it is the one that takes the least code to write ^[8]. That is the uncomfortable ordering: the cheapest repository test to write is the one whose green tells you least.

Of the three failure modes named, a strict column constraint, a broken mapping, and a query that only breaks against a real dialect, none can be observed without SQL reaching the database ^[9]. A save-then-findById test in a single persistence context issues none ^[5], so its detection rate against that set is zero ^[14].

Pushing the flush and clear into infrastructure is a bet about human behaviour rather than about Hibernate: per-method boilerplate is what gets dropped under deadline pressure, so the discipline goes into a test-only proxy that wraps every DAO and forces the sequence after any write ^[11][12]. The boundary is physical rather than conventional. The proxy lives in TestConfig under src/test/java, cannot be reached from production code, and never ships in a production artifact, with production wiring injecting the unproxied DAOs so write-behind batching survives outside tests ^[13].

The production half of the argument is one practitioner's account. Writing in Chapter 7 of the Evolutionary Architecture series on dev.to ^[17], the author says he has watched teams ship confidently on tests that only ever validated first-level cache state, until a missing constraint violation or a column mapping bug surfaced in production because the data was never flushed and re-hydrated ^[4]. No teams are named and no incident count is given. The mechanism, though, does not need his anecdote to be checked: drop a clear into an existing save-then-load test and the assertions that were riding on the object reference are the ones that break ^[1][2][16].