Skip to content

Inline snapshots - #12

Merged
SimonCropp merged 18 commits into
mainfrom
inline-snapshots
Aug 26, 2026
Merged

Inline snapshots#12
SimonCropp merged 18 commits into
mainfrom
inline-snapshots

Conversation

@SimonCropp

@SimonCropp SimonCropp commented Aug 26, 2026

Copy link
Copy Markdown
Member

https://github.com/VerifyTests/Verify/blob/main/docs/inline-snapshots.md

Adds inline snapshot support, so review, accept and reject handle inline snapshots beside file snapshots and a run that produced both is dealt with in one pass.

What changes

  • ISnapshot splits the file-based Snapshot from the new InlineSnapshot, and the finder, differ, renderer, manager and commands all work over the abstraction.
  • Accepting an inline snapshot rewrites the string literal in the test source rather than moving a file. review heads it with the call site and marks it (inline).
  • Two sources are read, because a test run hands its patch to whichever process owns the inline queue (DiffEngineTray, else the DiffEngineViewer the run launched) and only stages it under obj/VerifyInline/ when nothing answers. A tool that read one of them would report nothing pending for half its users.
  • When an owner is there, the accept is delegated to it, keeping one writer per source file and leaving the tray, the viewer and this tool agreeing about what is still pending.
  • Two refusal cases report themselves and let the rest of the run continue: a multi-targeted run whose frameworks disagreed about the content (one snapshot per framework for the same call site, so accepting would be picking between them silently), and a call site that can no longer be located because the Snapshot(...) call itself changed.

Notes

  • Requires DiffEngine 20.0.0-beta.34 and Verify 32.0.0-beta.14 — the SettleAppliedInline verb this relies on ships there.
  • README has an "Inline snapshots" section covering where pending inline snapshots come from and why a snapshot may refuse to be accepted.
  • Covered by unit tests over the finder, manager and renderer, plus integration tests that stand up a fake queue host.

SettleInline stamps the running process's own framework as the origin, which
here is this tool's rather than the test project's. The tool targets
net10.0;net8.0 and the entry carries whatever the test project targets, so
the two matched only by coincidence. On a mismatch the owner strips nothing
and answers no differently than if it had, so the entry stayed pending
against source that already held the snapshot, silently.

SettleAppliedInline carries no framework, which is the true statement: the
literal every variant was anchored to has gone, so none of them can apply.
It also takes the patch, so MemberName goes along and the entry is still
found once an earlier accept has pushed its line down the file.
SettleAppliedInline is not released yet. Points at DiffEngine's working tree
via pack-local.ps1 so this branch builds.

Revert this commit and pin DiffEngine to the published version once it ships.
CI cannot build the branch until then.
DiffEngine 20.0.0-beta.33 carries SettleAppliedInline, so the working-tree
feed the TEMPORARY commit added has nothing left to serve.
An Unknown accept with staged files falls back to applying the patch here, and
a discard the owner could not be asked about is treated as done. Only the
opposite of each was covered, so a mutation of either branch passed the suite.

Both new tests were checked against such a mutation rather than only run green:
flipping the condition each pins fails that test and nothing else.
The guard points every inline queue exchange this process makes at a port
nothing listens on, but it lived in the integration Harness, so the unit tests
had none: one that applies a staged patch settles it with the owner afterwards,
and that settle went to whatever tray happened to be running on the machine.

Now a module initializer in a file both test projects compile, so it runs before
any test in either and cannot be skipped by one that builds no harness. The port
is picked once per assembly rather than once per Harness: re-pointing per harness
would clobber a live InlineQueueHost if one were ever constructed first, which is
a worse risk than the OS reusing a port it just handed out.
@SimonCropp
SimonCropp merged commit 7f75034 into main Aug 26, 2026
2 checks passed
@SimonCropp
SimonCropp deleted the inline-snapshots branch August 26, 2026 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant