Context
DurableFile is what makes SPEC §5 durability true. The job counter, the session record, the published-batch history and atomic batch publication all go through it — so a defect here is invariant #1, never lose an acknowledged page, failing quietly.
It has no tests. grep -rn 'DurableFile' Tests/ returns exactly one hit in the whole test tree (Tests/ScanDeckImagePipelineTests/BatchPublisherTests.swift:426), and that call uses flush as setup for a different assertion. Nothing exercises write or rename, and no test asserts any DurableFileError case.
It is pure filesystem code — no AppKit, no scanner, no ImageCaptureCore. This is the easiest high-value suite in the repository to write.
What to change
New file Tests/ScanDeckCoreTests/DurableFileTests.swift. Model the temp-directory harness on Tests/ScanDeckCoreTests/JobCounterStoreTests.swift — every test must inject a temp directory; nothing may touch real user state.
The API is in Sources/ScanDeckCore/DurableFile.swift: flush(_:), rename(_:to:), write(_:to:).
Behaviours worth pinning:
write creates intermediate directories.write leaves no .<uuid>.tmp sibling behind — on success or on failure.- Overwriting an existing file replaces it atomically.
flush on a missing path throws DurableFileError.cannotOpen.rename to a path on another volume throws .cannotRename.
The sharpest untested edge is in rename itself: the destination directory is flushed after Darwin.rename has already succeeded, so a throw from that flush reports failure for a move that actually happened. Pin whichever behaviour is intended and say which in the PR — if you think it is wrong, open that as a separate issue rather than changing it inside a test PR.
Use Swift Testing (@Suite / @Test / #expect), not XCTest.
How to verify
swift test --filter DurableFileTests
swift test -c release
See CONTRIBUTING.md. No scanner needed.
Context
DurableFileis what makes SPEC §5 durability true. The job counter, the session record, the published-batch history and atomic batch publication all go through it — so a defect here is invariant #1, never lose an acknowledged page, failing quietly.It has no tests.
grep -rn 'DurableFile' Tests/returns exactly one hit in the whole test tree (Tests/ScanDeckImagePipelineTests/BatchPublisherTests.swift:426), and that call usesflushas setup for a different assertion. Nothing exerciseswriteorrename, and no test asserts anyDurableFileErrorcase.It is pure filesystem code — no AppKit, no scanner, no ImageCaptureCore. This is the easiest high-value suite in the repository to write.
What to change
New file
Tests/ScanDeckCoreTests/DurableFileTests.swift. Model the temp-directory harness onTests/ScanDeckCoreTests/JobCounterStoreTests.swift— every test must inject a temp directory; nothing may touch real user state.The API is in
Sources/ScanDeckCore/DurableFile.swift:flush(_:),rename(_:to:),write(_:to:).Behaviours worth pinning:
writecreates intermediate directories.writeleaves no.<uuid>.tmpsibling behind — on success or on failure.flushon a missing path throwsDurableFileError.cannotOpen.renameto a path on another volume throws.cannotRename.The sharpest untested edge is in
renameitself: the destination directory is flushed afterDarwin.renamehas already succeeded, so a throw from that flush reports failure for a move that actually happened. Pin whichever behaviour is intended and say which in the PR — if you think it is wrong, open that as a separate issue rather than changing it inside a test PR.Use Swift Testing (
@Suite/@Test/#expect), not XCTest.How to verify
See CONTRIBUTING.md. No scanner needed.