Test quak backup end to end against a fake of the Ente HTTP API #186

Closed
opened 2026-10-14 01:31:48 +02:00 by clawbot · 1 comment
Collaborator

Problem

No test runs quak backup the way a user runs it. test/cli/backup.test.ts drives the backup through a stand-in for quak's own library client and content source, with no encryption and no HTTP. The parts that only meet in a real run (the saved session, Client, the refresh, the download and decryption, the hash check, the live photo unpacking, the retries, and the exit codes) are each tested alone, never together. The repository already has fakes of the Ente HTTP API with real encryption (buildServer and buildMockFetch in test/client/usage.test.ts, buildMetaFetch in test/cli/metadata-backup.test.ts).

Definition of done

A test file under test/cli/ runs backupCommand from src/cli-commands.ts with the real loadSession reading a session file written by saveSession, its fetch pointed at a fake of the Ente HTTP API that serves encrypted data built with quak's crypto. Nothing of quak's own code is replaced. The retry waits are stubbed through RetryOptions.sleep, so the file stays within the suite's time limit. It covers:

  • an account with two albums of its own and one shared with it, a JPEG with EXIF in both of its own albums, a video, and a live photo: the tree on disk is the one "Backup layout" describes (save paths, each file's JSON with its ML data and image metadata, the live photo's two files and its JSON, album folders and their JSON, account.json), and the exit code is 0;
  • a second run downloads nothing and exits 0;
  • a file whose download fails twice with 503 and then succeeds is stored, with exit 0;
  • a file whose download always answers 404 is in failures.json, the rest is stored, and the exit code is 1;
  • a refresh answered with 401 exits 3 and writes nothing but the lock;
  • --verify after an original was changed on disk puts back the right bytes and exits 0.

If a case shows a defect, leave that case out of the PR, describe it on this issue (what you ran, what happened, what the README says should happen), and say so in the PR body. Do not fix product code in this PR.

Notes for the implementer

  • Reuse the existing fake server code; if it has to move into a shared file under test/ so both tests can use it, move it without changing what it does.
  • Comment the test as the README's "Development workflow" asks: a reader who has never seen quak should learn from it how a backup behaves.

Model: opus-5-5

## Problem No test runs `quak backup` the way a user runs it. `test/cli/backup.test.ts` drives the backup through a stand-in for quak's own library client and content source, with no encryption and no HTTP. The parts that only meet in a real run (the saved session, `Client`, the refresh, the download and decryption, the hash check, the live photo unpacking, the retries, and the exit codes) are each tested alone, never together. The repository already has fakes of the Ente HTTP API with real encryption (`buildServer` and `buildMockFetch` in `test/client/usage.test.ts`, `buildMetaFetch` in `test/cli/metadata-backup.test.ts`). ## Definition of done A test file under `test/cli/` runs `backupCommand` from `src/cli-commands.ts` with the real `loadSession` reading a session file written by `saveSession`, its `fetch` pointed at a fake of the Ente HTTP API that serves encrypted data built with quak's crypto. Nothing of quak's own code is replaced. The retry waits are stubbed through `RetryOptions.sleep`, so the file stays within the suite's time limit. It covers: - an account with two albums of its own and one shared with it, a JPEG with EXIF in both of its own albums, a video, and a live photo: the tree on disk is the one "Backup layout" describes (save paths, each file's JSON with its ML data and image metadata, the live photo's two files and its JSON, album folders and their JSON, `account.json`), and the exit code is 0; - a second run downloads nothing and exits 0; - a file whose download fails twice with 503 and then succeeds is stored, with exit 0; - a file whose download always answers 404 is in `failures.json`, the rest is stored, and the exit code is 1; - a refresh answered with 401 exits 3 and writes nothing but the lock; - `--verify` after an original was changed on disk puts back the right bytes and exits 0. If a case shows a defect, leave that case out of the PR, describe it on this issue (what you ran, what happened, what the README says should happen), and say so in the PR body. Do not fix product code in this PR. ## Notes for the implementer - Reuse the existing fake server code; if it has to move into a shared file under `test/` so both tests can use it, move it without changing what it does. - Comment the test as the README's "Development workflow" asks: a reader who has never seen quak should learn from it how a backup behaves. Model: opus-5-5
clawbot added this to the 1.0.0 milestone 2026-10-14 01:33:14 +02:00
Author
Collaborator

#191 adds test/cli/backup-end-to-end.test.ts, covering all six cases above. No case showed a defect, so none was left out. The fake server and the account it logs in moved from test/cli/metadata-backup.test.ts into test/ente-server.ts unchanged, and both tests use them.

Model: opus-5-5

https://git.eeqj.de/sneak/quak/pulls/191 adds `test/cli/backup-end-to-end.test.ts`, covering all six cases above. No case showed a defect, so none was left out. The fake server and the account it logs in moved from `test/cli/metadata-backup.test.ts` into `test/ente-server.ts` unchanged, and both tests use them. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/quak#186