test: give the rePlot snapshot its own name (fixes a hard ERROR on all Linux/Windows legs)

[eliotmcintire]

What

Two commits:

1. b9a1ce6 — give the rePlot snapshot its own name. test_that("rePlot doesn't work") took two snapshots under a single name: announce_snapshot_file() + expect_snapshot_file() twice with the same fil, unlink()ing the file in between. testthat rejects a duplicate snapshot name, so the second call errored and aborted the test:

   ── Error ('test-Plot-snapshots.R:612:5'): rePlot doesn't work ──
   Snapshot file names must be unique. "rePlot_doesn't_work1Linux.png" has already been used.
   

   The second snapshot now gets its own name derived from the first — sub("\\.png$", "-rePlot.png", fil) — rather than a second fn() call, because fn() bumps the shared counter and that would renumber every snapshot after this one. unlink(fil) goes with it; it only existed to clear the path for reuse.

2. 2724b9d — record three missing fixtures, taken from this branch's own run 33897686977, not rendered locally (expect_snapshot_file() compares PNG bytes exactly, and those bytes depend on the runner's cairo/fontconfig):

   File	Why
   rePlot_doesn't_work0Win-rePlot.png	new, from commit 1
   rePlot_doesn't_work1Linux-rePlot.png	new, from commit 1
   Plot_listsggplotVnewer2Linux.png	pre-existing gap — only the …2Win.png variant had ever been committed, so :703 reported "Adding new file snapshot" on every Linux leg

   Both rePlot images come out byte-identical to their non-rePlot counterparts already in the repo — which is precisely the assertion the original code was reaching for with "same file for snapshot b/c basename is same as previous": rePlot() reproduces the plot pixel for pixel. It just could not express that through a name testthat had already seen.

This was not caused by the CI migration

The identical failure set is in the development run from 2026-08-29, run 33278110145, before PR #44 existed. It went unnoticed because the old R-CMD-check.yaml triggered on [master, development] and there is no master branch, so R-CMD-check never ran against main. macOS was always green because oses <- c("Win", "Linux") (helper-testInit.R:83) — no snapshot test runs there at all.

Result — run 33899141206

Leg	Before	After
ubuntu-latest × 4 (devel, release, oldrel-1, oldrel-2)	FAIL 2	✅ green
macOS-latest (release)	green	✅ green
windows-latest × 4	FAIL 5	FAIL 4
test-coverage	❌ failure	✅ success

PASS went 173 → 174 on Linux.

What is left, and why it is not fixed here

The four remaining Windows failures are rendering drift against committed references — Issue 20; arr working (:765) and Issue 32 Plot factors lower case id (:793 ×2, :812). Measured pixel-for-pixel, they come to 7 changed pixels out of 1,920,000, max channel delta 58/255, and in every case the changed pixels sit inside a text glyph — a plot title maps$forestAge, or the legend label A. Font antialiasing on the windows-latest runner image, not a plotting change.

Accepting them is a judgement call about reference images, so it is left to the maintainer rather than folded into this PR.

Worth considering separately

expect_snapshot_file() compares PNG bytes exactly, so a one-pixel change in a font rasteriser is indistinguishable from a real regression. A tolerance-based comparator (compare = function(old, new) … with a small per-pixel budget) would keep the signal and drop this class of failure. Out of scope here.

Related

The _R_CHECK_DEPENDS_ONLY_ leg fails for a different, structural reason — handled in #46.

🤖 Generated with Claude Code

https://claude.ai/code/session_011kpoQV6nNqcknk16R3RzBB