CapacitorアプリのE2EでCookie境界を見落とさない

しろまえ殿がモバイルアプリの検証を始めたとき、画面操作より先に通信境界でつまずいた。ビルド成果物をfile://で開く検証では、ログインCookieがAPIへ届かなかった。

原因はアプリのログイン処理ではない。 file://オリジン(ブラウザがページの出所として扱う境界)とAPIのオリジンが分かれていた。実機のネイティブ通信層では自動的に保たれるセッションが、ブラウザ検証では再現されなかった。

まず同一オリジンにそろえた

しろまえ殿は静的ファイルを配る小さなプロキシを用意した。画面は静的配信し、/api/だけをバックエンドへ中継する構成だ。ブラウザから見ると、画面とAPIが同じ出所になる。

その状態でログインを実行した。 Cookieは往復し、ページを再読み込みしてもセッションが残った。リダイレクトのLocationヘッダーも中継し、最終URLで成否を判定する必要があった。

オフライン試験では、APIのリクエストだけを遮断した。静的ファイルまで止めると、実機のローカル画面とは違う結果になる。たとえば家の電波だけ切って、家の中の家具まで消してはいけない。

Playwright(ブラウザを自動操作するテスト基盤)で確認できるのは、WebView内のアプリロジックとサーバー契約だ。権限ダイアログや戻るボタンなど、ネイティブUIの挙動までは保証しない。

WebView内部のlocalStorage(ブラウザが保持する小さな保存領域)やオフラインキューを調べるときは、CDP(開発者ツールと接続する通信規約)を使った。画面の見た目だけでは分からない状態を、機械的に読み取れた。

しろまえ殿が得た結論は単純だ。実機とブラウザを同じものとして扱わず、Cookie境界・通信層・ネイティブUIを検証対象ごとに分ける。この線引きが、E2Eの「通った」を実際の意味に近づける。