4Hえんぴつ｜React＋TypeScriptでWeb RPGを作る
第7章「テストと品質管理」
第39回：console warning／pageerrorもE2Eの失敗条件にする
1. E2Eが最後まで通れば、本当に正常なのか
前回は、Playwrightを使って、
タイトル画面からキャラクターを作成し、町へ進み、セーブやロード、破損セーブからの復旧までを、実際のブラウザ操作として確認する方法を扱いました。
ここで、一つ問題があります。
テストが最後まで進み、
期待した画面が表示された
としても、ブラウザ内部では問題が起きている可能性があります。
例えば、Reactの処理中に例外が発生していたり、開発者コンソールに警告が出続けていたりしても、たまたま画面操作そのものは継続できることがあります。
そこで今回は、
画面上の成功だけでなく、ブラウザ内部で異常が起きていないこともE2Eの合格条件にする
方法を考えます。
2. 「操作できた」と「問題がない」は同じではない
例えば、E2Eで次の流れが成功したとします。
タイトルから「はじめから」を選び、キャラクターを作成して町へ到着する。
画面だけを見ると正常です。
しかし、その途中でブラウザコンソールに、
console.error
が出ているかもしれません。
あるいは、JavaScriptの未処理例外が発生していても、問題のない画面部分だけが残っている可能性があります。
つまり、
ユーザー操作が最後まで進んだことと、アプリ内部が健全であることは別です。
3. Playwrightではブラウザ内部の異常も監視できる
Playwrightでは、画面操作だけでなく、ブラウザで発生したイベントも取得できます。
代表的なのが、
console
と、
pageerror
です。
consoleでは、ブラウザの開発者コンソールへ出力された内容を監視できます。
pageerrorでは、ページ内で発生した未処理例外を検出できます。
この二つを、通常のE2Eシナリオと同時に監視します。
4. console.errorを見逃さない
画面操作が成功していても、内部でエラーが発生していれば、将来別の操作で問題になる可能性があります。
そのため、E2E開始時にコンソール出力を監視します。
以下は考え方を説明するため、実装を簡略化しています。
const consoleErrors: string[] = [];
page.on("console", (message) => {
if (message.type() === "error") {
consoleErrors.push(message.text());
}
});
シナリオ終了後に、
以下は考え方を説明するため、実装を簡略化しています。
expect(consoleErrors).toEqual([]);
と確認すれば、画面操作が成功していても、console.errorが発生していればテストを失敗させられます。
5. warningも品質条件に含める
エラーだけでなく、正式公開前の品質確認ではwarningも確認対象にしました。
warningは必ずしも不具合ではありません。
しかし、例えばReactやアクセシビリティ、廃止予定APIなどに関するwarningが残っている場合、
今すぐゲームが止まるわけではないが、何か見落としている
可能性があります。
そのため、公開候補では、
説明できないwarningを残さない
方針にしました。
以下は考え方を説明するため、実装を簡略化しています。
const consoleIssues: string[] = [];
page.on("console", (message) => {
if (
message.type() === "warning" ||
message.type() === "error"
) {
consoleIssues.push(message.text());
}
});
最終的に、この配列が空であることを確認します。
6. すべてのconsole出力を失敗にするわけではない
console.logまで禁止すると、開発中のログがあるだけでE2Eが失敗してしまいます。
重要なのは、
何を異常とみなすかを決める
ことです。
今回の正式公開判定では、少なくとも、
console warning
console error
を0件にすることを品質条件にしました。
ログの扱いはプロジェクトによって変えられますが、合格条件は明示しておく必要があります。
7. pageerrorはconsole.errorとは別に見る
もう一つ重要なのが、pageerrorです。
これは、ページ内で発生した未処理のJavaScript例外を検出します。
例えば、画面の一部分で例外が起きても、React全体が完全には停止せず、E2Eの次の操作へ進めてしまうことがあります。
そこで、pageerrorも監視します。
以下は考え方を説明するため、実装を簡略化しています。
const pageErrors: Error[] = [];
page.on("pageerror", (error) => {
pageErrors.push(error);
});
シナリオ終了後には、
以下は考え方を説明するため、実装を簡略化しています。
expect(pageErrors).toHaveLength(0);
と確認します。
8. なぜconsole.errorだけでは足りないのか
JavaScript例外が、必ずしも自分たちのconsole.error()として出力されるとは限りません。
一方、アプリ側が意図的に出したconsole.error()が、必ず未処理例外になるとも限りません。
そのため、
console監視とpageerror監視は別々に持つ
方が安全です。
整理すると、E2Eでは、
「期待した画面になったか」
「console warning/errorがないか」
「pageerrorがないか」
をそれぞれ確認します。
9. 失敗条件をE2Eの共通処理にする
各テストへ毎回同じ監視処理を書くと、入れ忘れが起こります。
例えば、
キャラクター作成テストでは監視しているが、セーブ復旧テストでは監視していない、
という状態です。
そこで、できるだけ共通化します。
考え方としては、
E2E開始時に監視を設定し、
テストシナリオを実行し、
最後にブラウザ内部エラーが0件であることを確認する、
という形です。
そうすれば、
どのE2Eでも同じ品質基準
を適用できます。
10. Recoveryシナリオでも内部エラーを見る
特に重要なのが、破損セーブからのRecoveryです。
例えば、
currentが壊れていて、backupから復旧できた。
画面上では続きを遊べた。
それだけなら、テストは成功に見えます。
しかし内部で、
Recovery途中に例外が発生していたり、
一度エラーになってから偶然backupロードへ進んでいたりすれば、
安心できません。
そのため、
異常系E2Eほどconsole／pageerror監視の意味が大きくなります。
11. future schemaでも「正しく止まった」ことを見る
future schemaの場合は、通常ロードを拒否することが正常動作です。
つまり、
エラー画面にならなかったから成功
という話ではありません。
期待しているのは、
現在のアプリでは扱えないと正しく判断し、
通常ロードせず、
通常上書きもせず、
元データを保持し、
さらに予期しないJavaScript例外も発生しないことです。
「止める仕様」でも、内部では正常に処理されている必要があります。
12. 期待したエラーと想定外のエラーを分ける
アプリによっては、意図的にエラー状態を表示することがあります。
例えば、
このセーブデータは現在のバージョンでは読み込めません
という表示です。
これは仕様上の状態であり、JavaScript例外である必要はありません。
つまり、
業務上・ゲーム上のエラー状態と、プログラムの異常を分ける
ことが重要です。
ユーザーへエラーメッセージを表示しているからといって、console.errorやpageerrorを出してよいとは限りません。
13. シナリオ成功＋内部エラー0をPASS条件にする
E2Eの合格条件を整理すると、単純な、
最後の画面まで進んだ
だけではありません。
例えばRecoveryなら、
「backupから復旧して続きを遊べる」
ことに加えて、
「console warning/error 0」
「pageerror 0」
まで確認します。
つまり、
機能結果と実行中の健全性を両方見る
ということです。
14. 失敗したときに原因を残す
E2Eが失敗した場合、
単に、
Expected 0, received 1
だけでは調査しづらくなります。
どのconsole出力だったのか、
どんなpageerrorだったのか、
を確認できるようにしておきます。
さらにPlaywrightでは、
trace、
screenshot、
video
なども残せます。
これらを組み合わせると、
どの操作のあと、画面がどうなり、ブラウザ内部で何が起きたか
を追いやすくなります。
15. 「テストが赤くなった」ことを不具合と即断しない
E2Eでは、アプリの問題だけでなく、テスト環境側の問題も起こります。
実際、正式リリース前の検証でも、Vitest workerの起動タイムアウトのように、アプリ本体ではなく試験環境を切り分ける必要があるケースがありました。
そのため、
テスト失敗 ＝ 即アプリ不具合
ではありません。
ただし、だからといってテストを無視するのではなく、
アプリ、
テストコード、
ブラウザ、
実行環境
のどこで失敗したのかを切り分けます。
テスト自動化では、この切り分けも品質管理の一部になります。
16. 正式公開版では0件をRelease Gateにした
現在の正式公開版では、最終品質保証として、
console warning/error 0件
pageerror 0件
を確認しています。
さらに、
Chromium 15/15、
WebKit＋iPhone emulation 7/7、
local hosting 7/7、
production hosting 7/7
までPASSしています。
つまりconsole／pageerror確認は、単なる開発中の参考情報ではありません。
正式公開してよいかを判断するRelease Gateの一部
になりました。
17. 今回のポイント
今回のポイントは3つです。
E2Eでは、画面操作が最後まで成功しただけでPASSにしません。
console warning/errorとpageerrorを監視し、ブラウザ内部で想定外の問題が起きていないことも確認します。
そして、異常系の画面表示と、プログラム上の異常を分けます。
つまり、
「遊べた」だけでなく、「内部でも壊れずに遊べた」ことを確認する
のが今回の品質基準です。
18. 次回
次回は、
Chromiumだけで終わらせない――WebKit・iPhone・A11yまで確認する【第40回】
です。
ここまでのE2Eで、プレイヤー操作とブラウザ内部の異常を確認できるようになりました。
しかし、Webアプリは一つのブラウザだけで動くわけではありません。
特に今回のWeb RPGは、
スマートフォン縦持ち
を主対象にしています。
そこで次回は、Chromiumだけでなく、
WebKit、
iPhone emulation、
実機iPhone Safari、
レスポンシブ、
アクセシビリティ
まで、どのように受入範囲を広げたのかを整理します。
この記事を最後まで読んでいただき、ありがとうございます。
「いいね」を押していただけるとうれしいです。これからの記事づくりの励みになります。
もし気に入っていただけましたら、フォローもよろしくお願いします。
前の記事
第38回 手動確認していた冒険をPlaywrightでE2Eテストにする
次の記事
第40回 Chromiumだけで終わらせない――WebKit・iPhone・A11yまで確認する
連載トップ
第0回 React＋TypeScriptで異世界RPGを作る――連載の目的と開発ロードマップ
note関連記事
手動確認していた冒険を、E2Eテストにする #21
noteでは、手動確認していた冒険の流れをPlaywrightへ移し、シナリオ成功だけでなくconsole warning/errorやpageerrorも確認対象にした背景を、制作側の視点から書いています。