📖
読書メモ：[入門]WebフロントエンドE2Eテスト PlaywrightによるWebアプリの自動テストから良いテストの書き方まで
前提
- リグレッションテストの自動化としてPlaywrightの実装を始めているが、『テスト・実装ともにコードが変わっていないのに、失敗したり成功したりする』という課題がある。この解決を目指しつつ、体系的な知識を得るためにこの本を読み始めた。
- 当記事の筆者はE2Eテスト（システムテスト）を専門とするテスター・QAで、実務でコードを読み書きした経験はない。
概要
- ハンズオンでのツール導入、ロケーター・アクション・マッチャーという基本的な操作、壊れにくいテストの実装、E2Eとそれ以外も含めたテスト戦略の立て方、テストの原則など、Playwrightについての広範な知識を得られる点が、本書の大きな価値だ。
- その中でも「Playwrightでのアクション(操作)は、想像していたよりなんでもできる」ことが印象的だった。マウスホバーやドラッグドロップなど。
- ただしドラッグ・ドロップは座標をハードコーディングする必要があるので、実際の運用は難しいだろう。
- 具体的に言うと、『リストの一番目と二番目の値を、ドラッグドロップで入れ替える』ではなく『x:200,y:200の位置からx：400,y：400の位置にドラッグ・ドロップする』という操作になる。このような手順は、『入れ替え操作というふるまいを変えずに、UIの細部だけを変更する』という改修に追従できない。
- このようなテストはリグレッションテストの本懐である『ふるまいが同じであればOK、ふるまいが変わってしまったらNGを出す＝バグとして検知する』という性質を損ねる。UIの変更により容易に壊れる(Flakyな)テストと呼ばれるもので、避けるべきだ。
- CursorでPlaywrightのコードを実装していると、やたら固定時間を待つ(ハードウェイト)のコードを書く癖があるが、本書では明確に否定されている。
- 例えば『5秒待つ』という手順だと、サーバーのレスポンス速度などの安定しない挙動によって成功と失敗が左右されてしまうかもしれない。それを避けるためにバッファを持たせて『10秒待つ』としてしまうと、テストの実行速度が遅くなる。複数個所で指定してしまうとなおさらだ。
- また通常のコーディングと同様、ハードコーディングされた値は意味を読み取るのに負荷がかかる。『5秒待つ』ではなく、『URLがxxに切り替わるまで待つ』『APIのレスポンスが返ってくるまで待つ』と実装した方が意味を読み取りやすい。
まとめ
- 目下の課題である『テスト・実装ともにコードが変わっていないのに、失敗したり成功したりする現象』のヒントは得られなかったが、本書の問題ではなく私自身の知識・経験不足によると考えている。Playwrightだけでなくフロントエンド・バックエンドのコード、インフラやネットワークを含めた広範な知識が必要なのかもしれない。
- 本書に加え、公式のベストプラクティスを読み込むことでよりよいテストを実装できるようになるだろう。
Discussion