A storage adapter that gets one rule wrong can lose work quietly. The fastest way to test a storage adapter is verifyStorageAdapter. It runs the storage contract against your adapter and reports each check.
Run the check
import { verifyStorageAdapter } from "fabricjs-document-engine/storage";
const report = await verifyStorageAdapter(restStorage);
if (!report.ok) console.table(report.checks);report is { ok, checks }. Each check is { name, passed, message }.
What it checks
| Check | Why it matters |
|---|---|
Saves a new document when expectedRevision is 0 | New documents can be stored |
| Loads the document it saved | What you save is what you get back |
Refuses a save based on an old revision with SAVE_CONFLICT | Another tab cannot overwrite newer work |
| Accepts a save based on the current revision | Normal saves still work |
Overwrites when expectedRevision is null | "Keep my version" after a save conflict works |
| Rejects loading a document that does not exist | Missing documents fail clearly |
| Keeps, lists, loads and deletes versions | Only when the adapter has version methods |
The check writes test documents with random ids. When your adapter has a deleteDocument method, it removes them afterwards.
Where to run it
Run it once in development against a test database, or in your test suite:
import { expect, test } from "vitest";
import { verifyStorageAdapter } from "fabricjs-document-engine/storage";
test("the REST adapter follows the save rules", async () => {
const report = await verifyStorageAdapter(restStorage);
expect(report.checks.filter((check) => !check.passed)).toEqual([]);
});Do not run it against production data. When you test a storage adapter this way on every change, a broken revision check fails the build instead of a user's save.