お疲れ様です！株式会社 CastingONEで働いているフロントエンドエンジニアの岡本です！
今回は、社内で実施したTesting Libraryの生みの親であるKent C.Doddsさんのテストに関するブログの読書会についてのお話を書いていきます！
はじめに
弊社のフロントエンドチームは、以前はテストに対する意識がそれほど高くなく、下記の記事が出たころはあまりテストを書けていない状況でした。
その後、徐々にテストの重要性が社内で認識されるようになり、最近ではテストを書く機会が増えてきました。
しかし、私自身はどの部分に対してテストを書くのが有効的なのか、 また テストコード自体どのように書くのがいいのか 、などのテストのペストプラクティスがよくわかっておらず、テストを書くことに苦手意識を持っており、後回しにしてしまう時がありました。。
そんな中、同じチームにテストに詳しいエンジニアの方が加わり、テストに関する知識を共有してくださる機会が増え、私もテストを書くことに対して徐々に自信がついてきました。その中で、「Kent C.Doddsさんのブログ、めちゃくちゃ参考になるよ」という金言をいただき、ブログを読んでみたところ、テストに関する知識がめちゃくちゃ詰まっていて、とても勉強になりました！
これは、他のエンジニアにも知ってほしい＆テストに関する共通認識を持ちたい！ということで、社内でKent C.Doddsさんのブログ読書会を開催することにしました！
どういう読書会を行ったのか
読書会の事前準備
まず、読書会で使用するKent C.Dodds（以下、ケントさん）のブログをまとめたNotionを作成しました。
- 自分がケントさんのテストに関するブログを読んで、以下のようなブログのリストをNotionで作成
自分がブログを読んで、「これは重要だ！」と思った度合いを右側の星で表現し、そのブログを優先して読んでいくようにしました。 - 各Notionのページは、以下のようにブログのリンクと、有志による日本語訳があればそのリンクを貼り、日本語訳がないブログに関してはChatGPTによる日本語訳を用意（軽く自分なりのまとめなども書いていました）
読書会の流れ
実際の読書会は以下のような流れで行いました。
- Notionを元に、毎週1時間の読書会を行う
読書会は自分がブログを全部読み上げるようにしました！また、読書会は録画しており、後から見返すことができるようにしています。 - ブログを読み終わった後、ブログに関して思ったことや実際にやってみたいことをNotionのかんばんに書き込んでもらう
- かんばんに書かれてる内容を元に、全員で感想戦を行う
この読書会を計11回行い、ケントさんのテストに関するブログを読破しました🎉
読書会で盛り上がったブログ紹介
読書会で議論が盛り上がった、または特に参考になったケントさんのブログを紹介します！
AHA Testing💡
-
ブログの概要
テストの抽象化の範囲について書かれています。ケントさん曰く、テストの抽象化は以下の3つのレベルがあるとのこと。- ANA (Absolutely No Abstraction): 全く抽象化しない
- AHA (Avoid Hasty Abstraction): 早すぎる抽象化を避ける
- DRY (Don't Repeat Yourself): 重複を避ける
ケントさんはAHAテストを推奨しており、適切な抽象化を行うことで、テストの可読性とメンテナンス性を向上させることができると述べています。
-
盛り上がった、参考になったポイント
テストに対して、
setup関数を用いて共通の処理をまとめるのいいね！という声が多く、テストを書く時、できるだけsetup関数を使おうという流れになりました！
Write tests. Not too many. Mostly integration.（テストを書きましょう。あまり多くなりすぎないように。主に結合テストで。）
-
ブログの概要
コンポーネントが独立して機能することを検証する単体テストをいくらか持つことは悪いことではないが、それらが適切に連携して機能すること も 検証しないとテストとしてあまり意味がないということを述べています。
結合テストは、信頼性とスピード/費用とのトレードオフの間で素晴らしいバランスを保つことができるとのこと。 -
盛り上がった、参考になったポイント
結合テストの重要性について、例として説明しているXの投稿がとても分かりやすく多くのメンバーが「なるほど！」と納得していました！
傘が開いているという単体テストのみだと動画のような状態でもテストが通ってしまうため、結合テストの重要性を再認識できました😂
Making your UI tests resilient to change（UIテストを変更に強いものにする）
-
ブログの概要
UIテストでテストしたい項目をrootNode.querySelector('.btn)のような、実際のユーザーが意識することのないクラスなどで取得することは、テストを変更に弱くしてしまう。テストはソフトウェアの使用方法に似ているほど、テストから得られる信頼性が高まるとのこと。また、リファクタリングや機能の追加時にテストを変更する必要がある場合は、テストが脆弱であることを示しているとのこと。
-
盛り上がった、参考になったポイント
「テストがソフトウェアの使われ方に似てくるほど、より信頼性が高まる」という点について、多くのメンバーが「だからTesting LibraryはgetByRoleのようなユーザーが実際に操作する要素を取得するメソッドがあるんだなぁ」と感じていました！
当然、上記のブログ以外もめちゃくちゃ参考になるので是非読んでみてください！
おわりに
以上が、社内で行ったケントさんのブログ読書会についてのお話でした！予想以上に開発メンバーに好評で、毎回多くのフロントエンドメンバーが参加してくれていたので、フロントエンドメンバー全体でテストに対する共通認識が醸成されていったように感れて、開催してよかったなぁと思っています！是非、皆さんも社内でやってみてはいかがでしょうか？😊
Discussion