When arranging fixtures, why prefer TestEntityManager over repository.save, and what role do flush and clear play with the first-level cache?

## Two independent reasons ### Reason 1 — Test independence A good test's **Arrange** step should not depend on the **code under test**. If you're verifying `UserRepository.findActiveByEmail`, creating the fixture with `userRepository.save(...)` means a defect in `save`, in the entity's `@Column` mappings, or in a lifecycle callback could either break Arrange or, worse, make a wrong test pass. `TestEntityManager` gives you an insertion path that is deliberately *separate* from the repository you're checking, so the outcome reflects the query logic alone. ### Reason 2 — The first-level cache (persistence context) The JPA **persistence context** is a transaction-scoped **identity map**: within one transaction, each entity id maps to exactly one managed object. It's also called the **first-level cache**. Two consequences matter in tests: 1. After `persist(user)`, `user` is *managed* and lives in that map. If you then call `userRepository.findById(user.getId())` in the same transaction, JPA returns **the same in-memory instance without issuing a SELECT** — the identity-map guarantee. So your assertions inspect the object you constructed, not a row loaded from the DB. A column that doesn't actually round-trip (wrong name, `insertable=false`, a converter that only runs on read) can slip through. 2. Because `@DataJpaTest` uses one transaction per test, that cache persists across all your `persist`/`find` calls in the method. ## flush and clear - **`flush()`** synchronizes the persistence context with the database: pending INSERT/UPDATE/DELETE SQL is executed **now** (still inside the transaction). It does **not** empty the cache — entities stay managed. - **`clear()`** detaches **all** managed entities: the first-level cache is emptied and every object becomes *detached*. It does **not** send SQL. The combination is the key idiom. To prove data truly round-trips: ```java entityManager.persist(user); entityManager.flush(); // INSERT hits the DB entityManager.clear(); // empty first-level cache -> next read must reload User reloaded = userRepository.findById(user.getId()).orElseThrow(); ``` Now `findById` issues a real SELECT and materialises a fresh instance, so mapping bugs surface. `persistFlushFind` packages a similar idea (persist, flush, find-back). ## Order matters Always `flush()` **before** `clear()`. `clear()` discards pending changes that weren't flushed — if you clear before flushing, the queued INSERT is thrown away and your row never gets written. `flush()` first guarantees the SQL is sent; `clear()` then just forgets the in-memory copies. ## When each tool fits - **Read/query tests** that must confirm the DB mapping: `persist` + `flush` + `clear`, or `persistFlushFind`, then read. - **Constraint tests**: `persistAndFlush` to force the write and catch `DataIntegrityViolationException`. - **Simple existence checks** where mapping fidelity isn't the point: a single `persistAndFlush` may be enough. ## Gotchas - Forgetting `clear()` is the most common reason a mapping bug hides: the test reads from cache, not the DB. - `clear()` detaches entities, so lazy associations accessed afterward on the *old* instance throw `LazyInitializationException` (it's detached). Use the reloaded instance. - `TestEntityManager` and the repository share the same persistence context in the test, so `persist` via one is visible to `findById` via the other (that's exactly why the cache caveat applies).