【輪読会レポート】[入門]Webフロントエンド E2E テスト PlaywrightによるWebアプリの自動テストから良いテストの書き方まで 第10章「E2Eテストの実戦投入」
はじめに
こんにちは。ラクス フロントエンドチームのたぐちです。
今回は輪読会の実施レポートvol.8です。
書籍と読書範囲
今回の読書範囲は第10章 E2Eテストの実戦投入のP182~P200です。
議論・意見交換
学び、ギモン、その他の三軸で付箋を張り付け、付箋の内容を左上から順に読んで議論していきました。
実際の議論順で内容を確認していきます。
学び
10.1.2 > 操作系の列挙を行っていると網羅的なテストシナリオを作成したくなってきます。 分かる
E2Eテストでどこまで網羅的にテストするべきか、単体テストとの境界線が難しいという意見が出ました。
つい単体テストに近い内容までテストシナリオに組み込んでしまいがちなので、意識して線引きすることが重要ですね。
10.2.1 E2E用にリポジトリ切っちゃうのは大胆だけど良さそう
E2Eテストのために独立したリポジトリを持つことについては、管理のしやすさが向上するという意見がある一方で、CIへの組み込みが難しくなる可能性も指摘されました。
Webhookなどを活用すれば解決できるかもしれないので、さらに深掘りしたい内容です。
10.1.3 プロジェクト初期ではユニットテストに重きを置く
プロジェクト初期はユニットテストに注力し、カバーできない部分をインテグレーションテスト、E2Eテストと段階的に補完していくことで、理想的なテスティングトロフィーを構築できるという意見がありました。
10.1.3 テストにエラーが出たときに、アプリに不具合が出たのかテストが壊れたのか 重要
テストにエラーが出た際に、アプリ側の問題なのか、テストコード側の問題なのかを切り分けることは非常に重要です。
そのためには、信頼性の高いテストコードを記述することが大切ですね。
10.4.1 GitHub Projectsでテスト管理するのは距離が近い管理が出来るので是非やりたい
スプレッドシートなどでテストを管理するよりも、GitHub Projects を活用することで、コードとの距離が近くなり、管理が容易になり、諸々の自動化も期待できます。
ギモン
今回はギモンの付箋はありませんでした。
その他
10.3 cIのテストがこけた時、視覚的にどこコケたか見やすくてどんどん入れて欲しい
CIでのテスト結果を、ログだけでなくGUIで視覚的に確認できると便利だという意見がありました。
どこでエラーが発生したのかが一目でわかるようになれば、デバッグ効率も向上しそうです。
また、ローカルでのE2E実行は億劫になりがちなので、なるべくCIに組み込みたいという意見も。
まとめ
今回の輪読会レポートは以上です。
次回開催は09/03(火)の予定ですので、お楽しみに!
終わりに
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っています。ご興味ありましたら是非ご確認をお願いします。
採用情報
https://career-recruit.rakus.co.jp/engineer_jobs/frontend_tokyo/
https://career-recruit.rakus.co.jp/career_engineer/