How do you structure a data-access test so that its assertions observe state only after the unit-of-work boundary has closed?

The single structural change that makes data-access tests tell the truth is to stop letting one open unit of work span the whole test. What follows is the shape that works and the tradeoffs it carries. ## The three-boundary shape 1. **Arrange.** Seed the rows the scenario needs, then end that unit of work. Two things happen: the writes are actually emitted and accepted, and none of the seeded objects remain tracked, so the exercise phase must load them for real. 2. **Act.** Call the code under test the way production calls it — through the entry point that opens its own boundary per request, message or job. Critically, the test must not have an open transaction the production code silently joins; if it does, the boundary the code relies on never closes and the exercise is not the production shape. 3. **Assert.** Open a fresh unit of work, or read the columns directly with a plain `SELECT`, and check the state there. This is the only read that reflects what the database holds rather than what the test remembers. ## Why the assertion must be a re-read Asserting on the object the exercise returned is the most common way a test quietly stops proving anything. That object is the tracked instance the code just manipulated: its fields are whatever the code set, regardless of whether a statement was emitted, whether the engine rewrote a value, or whether the transaction committed. A re-read after the boundary crosses the gap between "the code believes it did this" and "the database contains this". ## Choosing the second observer | Observer | Shows | Costs / caveats | |---|---|---| | A fresh unit of work | What the mapper reads back, including its own conversions | Still goes through the mapping, so a symmetric mapping bug can cancel out | | A plain `SELECT` for the columns | Exactly what landed in each column | Verbose; couples the test to the schema | | Clearing the tracked set only | A real query instead of an identity-map hit | Same transaction, uncommitted view; no detachment | A symmetric bug — writing and reading a value through the same wrong conversion — is the case that argues for the plain `SELECT` on at least the fields that matter: identity, the linking column of an association, a status value another system reads, a monetary or temporal value where precision is easy to lose. ## What else becomes assertable once the boundary closes - **Usability of the returned graph.** If the production caller receives an object after the boundary and walks it, let the test do the same walk outside the boundary. A read of something never loaded then fails in the test instead of in production. - **What the operation actually emitted.** With the phases separated, the statements attributable to the exercise are exactly the ones the code under test caused, which makes counting them meaningful rather than polluted by setup. - **Ordering and constraint timing.** Checks that fire at commit rather than at statement time only fire when the boundary actually ends. ## The costs, honestly Committed test data has to be cleaned up, which is a real design decision for the suite and slower than never committing anything. Setup that goes through the boundary twice costs time. And some code cannot be invoked without its surrounding runtime, so "act the way production acts" is sometimes an approximation. The pragmatic answer is a tiered suite: - most tests stay cheap and check mapping and behaviour, with the tracked set cleared before the assertion so at least the identity map cannot answer; - a smaller tier commits and re-reads across true boundaries, covering the paths where the hand-off matters — anything returning a graph to a caller, anything that writes in a second context what it read in the first, anything with engine-supplied values; - a very small tier reads with plain `SELECT` on the fields where a symmetric mapping error would be expensive. ## The check to apply to any existing test Ask: *could this test still pass if no statement had ever been sent?* If yes, it is asserting on memory. Then ask: *does anything in this test observe the state through a different reader than the one that wrote it?* If nothing does, the test has no second opinion, and a second opinion is the entire point.