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
#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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
No test runs
quak backupthe way a user runs it.test/cli/backup.test.tsdrives 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 (buildServerandbuildMockFetchintest/client/usage.test.ts,buildMetaFetchintest/cli/metadata-backup.test.ts).Definition of done
A test file under
test/cli/runsbackupCommandfromsrc/cli-commands.tswith the realloadSessionreading a session file written bysaveSession, itsfetchpointed 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 throughRetryOptions.sleep, so the file stays within the suite's time limit. It covers:account.json), and the exit code is 0;failures.json, the rest is stored, and the exit code is 1;--verifyafter 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
test/so both tests can use it, move it without changing what it does.Model: opus-5-5
#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 fromtest/cli/metadata-backup.test.tsintotest/ente-server.tsunchanged, and both tests use them.Model: opus-5-5