見出し画像

【輪読会レポート】［入門］Webフロントエンド E2E テスト PlaywrightによるWebアプリの自動テストから良いテストの書き方まで 第5章「テストコードの組み立て方」

たぐち

はじめに

こんにちは。ラクス フロントエンドチームのたぐちです。

今回は輪読会の実施レポートvol.3です。

書籍と読書範囲


［入門］Webフロントエンド E2E テスト PlaywrightによるWebアプリの自動テストから良いテストの書き方まで(画像はこちらより引用)

今回の読書範囲は第5章 テストコードの組み立て方のP82～P98です。

議論・意見交換


議論の様子(miro)

学び、ギモン、その他の三軸で付箋を張り付け、付箋の内容を左上から順に読んで議論していきました。
実際の議論順で内容を確認していきます。

学び

  • 5.1.3 > きれいなテストをめざして導入が遅れるよりも、まずはテストを早く導入するのが先決です 刺さる…

これは耳が痛いですね…。ついつい完璧を目指してしまいがちですが、まずは手を動かすことが重要だと改めて実感しました。

  • 5.2.1 testInfoは出力ばかりで使っていたけど、入力もできるのか

  • 5.2.1 添付ファイル機能知らんかった

初めて知ったという意見が多数でしたが、使い道がその場では思いつきませんでした…。何か良い使い道はありますかね？

  • 5.2.1 p89 管理ユーザと一般ユーザーの...テスト時間が長くなりそうと不安ですが、便利な機能なのでたくさん活用しそう

便利機能で活躍の場も多そうですが、権限を細かくテストしていると組み合わせが無限になってしまうので費用対効果を意識することが大事ですね。

  • 5.4 E2Eテストのファイル画面ごとで分けがちだから、機能で分割するの新鮮

ユースケース単位での分割は、カバレッジ向上とメンテナンス性向上にも繋がり、ファイル名からテストケースの把握もしやすくなるので、良さそうです。是非試してみたいところ。

  • 5.3 それぞれの操作に対してもコメントをつけることは大切

  • p96 確かにテストコードもテストケース名だけだとwhyが伝わらないから積極的にコメント書くべきだよなぁと思った

describe と test だけでは、なぜそのテストが必要なのか、どのような操作を行っているのかが伝わりにくいことがあります。
Whyを伝えるコメントを積極的に書くことで、より分かりやすいテストコードを目指したいですね。

  • p91 > テストのグループ化 describe内にdescribeを書くとネストがどんどん深くなって可読性が落ちるので基本二段くらいまでにとどめておきたい

describe をネストさせてテストをグループ化していくことはよくあると思いますが、ネストが深すぎると可読性が低下する可能性があります。
ネストしそうなら2段にdescribeを書くのではなく、1ファイルでdescribeをもう一つ書くようにするとフラットに書けて良いという意見も上がりました。

ギモン

  • 5.2 結局、コンテキストって何？ 環境のこと？

「コンテキスト」という単語が抽象的で、具体的に何を指すのかが分からないという疑問でした。直訳は「文脈」ですが、「環境」と訳した方が伝わりやすそうという意見でまとまりました。

  • 5.2.1 E2Eテストで今まで排他実行とか試したことなかったけど、他社では結構やってたりするんだろうか

複数ユーザーの話から派生して、排他実行はE2Eテストでやるべきか、という疑問でした。これも実施するとテストケースが大きくなりそうな内容なので、やはり費用対効果で実施すべきか決めるべきという結論になりました。

  • 5.1.2 p.86 ユニットテストやインテグレーションテストで担保したモノは手動テストから除外してもいい独自ルールとかあります？

自動テストでカバーできている範囲を手動テストで再度実施するのは無駄が多いので、やりたくないけどやってしまっているというエピソードでした。
テストのカバー範囲を明確にすることで解消できる部分もあると思うので、是非やっていきたいですね。

その他

  • p86 > 「ユニットテストでやるべきテストまでplaywrightでやると〜」 playwrightだと書きやすいからやりたくなる

Playwrightは実際の動きが目で見えるし、テストが非常に描きやすいのでついPlaywrightでテストを書きたくなるけど、グッとこらえているというお話でした。

  • 5.5 p.97 スナップショットテストが失敗した時の結果よく理解していない。分かりにくい

スナップショットテストは、画面全体のスクリーンショットを比較することで、意図しない変更を検知できる便利な手法です。
しかし、失敗時の原因特定が難しいという側面もあるので、画面の変更検知はVRTに任せられると開発者としては嬉しいですね。

  • p94 onlyコミットしてしまいがち

一部のテスト修正時にonlyをつけて確認して、そのままコミットしてしまいがちというあるある話でした。
これはE2Eテストあるあるですね、すごく分かります。

まとめ

今回の輪読会レポートは以上です。
次回開催は07/23(火)の予定ですので、お楽しみに！

終わりに

ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っています。ご興味ありましたら是非ご確認をお願いします。

採用情報

https://career-recruit.rakus.co.jp/engineer_jobs/frontend_tokyo/
https://career-recruit.rakus.co.jp/career_engineer/

イベント情報

https://rakus.connpass.com/

この記事が気に入ったらサポートをしてみませんか？