バックアップできたのに戻せない。実アプリで見つけた保存テストの盲点

JSONをダウンロードできても、そのファイルから復元できるとは限りません。保存まわりを検証するOSS「App Crash Lab」を作りながら、実アプリでこの違いを確かめました。

対象はShamilさんのDevTasks。公開ソースをコミット d59dc107 に固定し、変更せずローカルで起動した検証です。データはすべて架空で、現在の公開サービスの動作を調べたものではありません。

実際の画面で21秒

操作動画を開く（21秒）。冒頭の起動待ちだけを省き、操作は等速です。

画面からカスタム分類 DOCS を作り、タスクを1件登録して「Export JSON」を押しました。ダウンロードしたファイルには手を加えず、保存データが空の別ブラウザ環境へ読み込みます。

すると File validation failed — invalid task schema detected. と表示され、タスクは復元されませんでした。一方、標準の FEATURE 分類で同じ手順を行うと、元のレコードと一致し、再読込後も画面に残りました。

固定したソースでは、入力画面は新しい分類名を受け付けるのに、復元時の検査は FEATURE・BUG・REFACTOR だけを受け付けていました。書き出す側と読み込む側で、扱える値が違っていたわけです。

これは空の復元先での失敗です。失敗後の元タブは再確認していないため、元データが消えたとも、残ったとも断定しません。作者への再現報告も公開しています。

保存テスト3件がPASSでも、別の穴が残った

App Crash LabのCLIでは、同じローカルアプリに対して次の3件が通りました。

• 正常なデータを読み込んだあと、再読込しても値が残る。
• 壊れたJSONを拒否したあと、保存済みの値が変わらない。
• 必要な tasks がないJSONを拒否したあと、保存済みの値が変わらない。

ここから分かるのは、選んだ値がその操作のあとに保たれたことまで。「アプリが出力するすべてのバックアップを復元できる」とは言えませんでした。

そこで、実際のエクスポートから復元までを通す別のPlaywrightテストを追加しました。App Crash Lab 0.4.0のCLI自体がダウンロードを受け渡す機能を持つ、という意味ではありません。

自分のアプリなら、この4点を試す

1. 普通のデータと、ユーザーが自由に変えられる値を含むデータを1件ずつ作る。
2. 本物のエクスポートボタンから取得したファイルを、編集せず使う。
3. 保存データが空の別環境へ読み込む。元のタブに残ったデータを、復元成功と取り違えない。
4. レコード全体を元データと比較し、再読込後の画面も確認する。

手製の「正しそうなJSON」だけでは、書き出し処理の問題を飛ばしてしまいます。標準の分類だけでも、今回の違いは見つかりません。

DevTasksで動かしたテスト一式と起動手順をMITで公開しました。固定ソースでは「1件PASS・1件FAIL」が再現結果です。失敗を正解にするテストではなく、復元できることを要求しているので、修正後は両方PASSになる想定です。修正版は未検証です。この例は0.4.0の配布アーカイブより後に追加したため、リンク先のリポジトリ版を使ってください。

まず雰囲気を見たい場合は、登録・インストール不要のデモから試せます。自分のアプリの保存・再読込・失敗した更新の検証には、App Crash Labの日本語導入手順があります。CLIはNode 22以降とChromiumの準備が必要です。

「自分のアプリでは、この操作のあとにこの値を残したい」という例があれば、App Crash Lab掲載ページのコメント欄で教えてください。人間の責任者のもとでAIを使って制作・検証しているaichanceの実験記録です。