A translation-memory updater bakes its output path in at import time. What seam makes its rollback testable?

### The seam, and why the constant blocks it A *seam* is a place where you can change behaviour without editing the code under test. When a writer resolves its destination itself — `STORE = Path(os.environ["TM_HOME"]) / "memory.tsv"` evaluated at import — there is no seam at all. The path is fixed before any test runs, so the only lever left is mutating the module's global, which couples every test to the module's internals and breaks the moment the constant is renamed or inlined. The fix is a parameter: ```python def update_memory(entries, store: Path = DEFAULT_STORE) -> None: ... ``` Production callers keep the one-argument call. The test passes its own path and exercises the shipped code path end to end, against a real filesystem, with no interception anywhere. That is the property that matters: nothing about the write is simulated, so encoding, permissions, rename semantics and the rollback branch are all genuinely tested. A few details make the parameter pull its weight: * **Type it as `Path` and normalise on entry** with `store = Path(store)`, so a caller passing a `str` or any `os.PathLike` still works. `Path` implements `os.PathLike`, so anything you pass it on to accepts it. * **Build children with `/`**, never string concatenation, and never a hardcoded separator. * **Decide directory-or-file deliberately.** Taking the directory and appending a fixed filename gives the caller less control but keeps the layout owned by the module; taking the full file path is more flexible. Pick one and be consistent, because tests read much better when the parameter means the same thing everywhere. * **A default that is an immutable `Path` is safe** to evaluate at `def` time — unlike a mutable default such as a list, there is nothing to accumulate. ### Making the partial-failure rollback observable Once the path is injectable, the interesting test becomes possible: what does the store look like when the update dies half-way? A truncate-and-rewrite implementation (`open(store, "w")` then a loop) has already destroyed the old content by the time entry three fails, so the answer is "a corrupt half-file" — and a service that reads it on start-up now fails on data it wrote itself. The standard shape is stage-then-swap: 1. Write the complete new content to a staging file beside the target — `store.with_suffix(".tmp")`. 2. `staged.replace(store)` once the write has finished. `Path.replace` maps to `os.replace`, which overwrites the destination and is atomic on POSIX: a concurrent reader sees either the whole old file or the whole new one, never a partial write. 3. On any exception, delete the staging file (`unlink(missing_ok=True)`) and re-raise. The target is untouched, which *is* the rollback. The atomicity has a hard boundary worth stating out loud in an interview: `os.replace` fails across filesystems. Staging into the platform temp directory and renaming onto a target on a different mount raises `OSError`, and the naive "fix" — copy instead of rename — throws the atomicity away. Stage in the target's own directory. With the seam in place the test is direct: create a temporary directory, write a known original into it, call the updater with an input whose serialisation fails part-way, catch the exception, then assert the original bytes are still there and that `list(tmpdir.iterdir())` contains only the target. Injecting the failure is itself a design question — a value that fails to serialise, a second injected callable that raises on the third record, or a target directory made read-only after the staging write. ### Why not just drive the real system The reflex answer is "run it against the real store in a staging environment". For a service with a 45-second cold start, that buys one assertion per minute and makes the failure branch, which requires killing the process at exactly the wrong moment, effectively untestable. A temporary directory plus an injected path exercises the same code in milliseconds and lets you provoke failures on demand. Keep the end-to-end run for the deployment question — does the process have permission to write where it is configured to — which is the one thing the temp directory genuinely cannot answer. ### The wider point Injecting the path is one instance of a rule: a function should not both *decide* what to touch and *do* the touching. Pull the decision up to the caller, where configuration lives, and the doing stays a small, testable function. The signature also becomes self-documenting — a reader can see that this function writes to exactly one place, which a module-level constant hides.