Test fixture: a throwaway iPod with no hardware #3

New issue

Open

opened 2026-08-25 22:19:36 +02:00 by wokoman · 0 comments

wokoman commented

2026-08-25 22:19:36 +02:00

(Migrated from code.nolog.cz)

What to build

Tests can stand up a real, empty iPod in a temporary directory and talk to it exactly as they would a mounted device — parse it, copy a track in, read the track back, remove it — with no hardware attached and nothing left behind afterwards.

Today the only constructor for a database is one that parses a mounted device, so every test that touches the copy or removal paths is #[ignore]d behind IRONPOD_MOUNT. That means the code with the most destructive failure modes is the code CI never runs. This ticket removes that constraint; it is a prefactor, and the tickets that follow are unverifiable without it.

libgpod can do this unaided: its initialisation entry point takes a mountpoint, seeds the model into a sysinfo file, creates the directory skeleton, adds a master playlist and writes an empty database. No physical device is involved anywhere in that path. It is already exposed through the existing bindings — no new FFI, no build changes.

Acceptance criteria

A test helper creates an empty iPod in a temp directory and returns a parsed database for it
The helper is visible to unit tests in src/ (integration tests in tests/ stay hardware-gated and are out of scope)
Cleanup is automatic, including when a test panics
A test proves the round trip: create a fixture, copy an audio file in, reopen it, and find the track with its metadata intact
The full test suite passes on a machine with no iPod attached, and adds no new #[ignore]
The temp directory and the database handle are released in the correct order, with a comment saying why the order matters — the handle points into the directory that cleanup deletes

Notes

Keep the helper private to the crate's own tests. There is a known community pattern for sharing fixtures with integration tests as well (a self dev-dependency behind a doc-hidden feature); it is deliberately not adopted here, because nothing in tests/ needs the fixture yet. Adopt it the day something does.

libgpod's initialisation function leaks its database handle on one error path — when directory creation fails. It is upstream, in vendored code, and affects only failed fixture setup. Noted, not fixed here.

Blocked by

None — can start immediately.

## What to build Tests can stand up a real, empty iPod in a temporary directory and talk to it exactly as they would a mounted device — parse it, copy a track in, read the track back, remove it — with no hardware attached and nothing left behind afterwards. Today the only constructor for a database is one that parses a mounted device, so every test that touches the copy or removal paths is `#[ignore]`d behind `IRONPOD_MOUNT`. That means the code with the most destructive failure modes is the code CI never runs. This ticket removes that constraint; it is a prefactor, and the tickets that follow are unverifiable without it. libgpod can do this unaided: its initialisation entry point takes a mountpoint, seeds the model into a sysinfo file, creates the directory skeleton, adds a master playlist and writes an empty database. No physical device is involved anywhere in that path. It is already exposed through the existing bindings — no new FFI, no build changes. ## Acceptance criteria - [ ] A test helper creates an empty iPod in a temp directory and returns a parsed database for it - [ ] The helper is visible to unit tests in `src/` (integration tests in `tests/` stay hardware-gated and are out of scope) - [ ] Cleanup is automatic, including when a test panics - [ ] A test proves the round trip: create a fixture, copy an audio file in, reopen it, and find the track with its metadata intact - [ ] The full test suite passes on a machine with no iPod attached, and adds no new `#[ignore]` - [ ] The temp directory and the database handle are released in the correct order, with a comment saying why the order matters — the handle points into the directory that cleanup deletes ## Notes Keep the helper private to the crate's own tests. There is a known community pattern for sharing fixtures with integration tests as well (a self dev-dependency behind a doc-hidden feature); it is deliberately **not** adopted here, because nothing in `tests/` needs the fixture yet. Adopt it the day something does. libgpod's initialisation function leaks its database handle on one error path — when directory creation fails. It is upstream, in vendored code, and affects only failed fixture setup. Noted, not fixed here. ## Blocked by - None — can start immediately.