久々に読書レビュー的なブログを書きました。
今回はフロントエンドのテストに関する書籍で、特に入門者向けにおすすめなものになります。
僕自身もそこまでフロントエンドまわりをやっていた訳ではないので、初心者目線で読ませて頂きました。
目次
書籍の目次はこのようになっています
| 章 | タイトル |
|---|---|
| 第1章 | テストの目的と障壁 |
| 第2章 | テスト手法とテスト戦略 |
| 第3章 | はじめの単体テスト |
| 第4章 | モック |
| 第5章 | UIコンポーネントテスト |
| 第6章 | カバレッジレポートの読み方 |
| 第7章 | Webアプリケーション結合テスト |
| 第8章 | UIコンポーネントエクスプローラー |
| 第9章 | ビジュアルリグレッションテスト |
| 第10章 | E2E テスト |
フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識 電子書籍｜翔泳社の本
1〜3章
教科書的に「テストはなぜやるのか？」「どのようなテストがあるのか？」などの基本的な内容が解説されていました。テストについて全くの知識がない方でも初歩的なところから学び始められるのでいいですね。
「テストを書く目的」という点は、どの視座で物事を見ているかでかなり変わってくる点なのではないでしょうか。目の前のタスクを処理している状態では、できるだけプログラミングする時間を多く確保したいと思うので、テストコードやその他の取り組みに関しては無駄だったり、今やらなくてもとつい思ってしまったりしますね。
この書籍にも書いてありましたが、バグがもたらす影響がどのようになるのかを1度視野を変えて見つめ直す機会にもなると思います。
個人的には特に「健全なコードを維持するためには」というところは共感できました。健全なコードを維持していくことの大切さは誰もが知っていることだと思いますが、その時の優先度や緊急度など置かれている状況によって時間と労力がかけられなかったり、VUCAな時代だと予想した通りに物事が進まず、将来的に役立つようにやっていた対策や処理が役に立たないことがあると少なくないと思います。これについては、既にYAGNIの法則などでご存知の方も多いのではないでしょうか。
コードが変更される状況は、プロダクトオーナーなどからの要望によって新機能や機能改修などが行われることもありますし、脆弱性や使用しているパッケージのバージョンアップに合わせてコードの修正を求められることもあります。
そのようなことを考えるとどんなにしっかりと考えてできるだけ修正しないようなコードを考えたとしても、外からのきっかけで変更が必要になる日は必ずやってきます。
そんな時にテストコードが正しく書けていれば、何か変更した時によくない修正を加えた場合にはすぐにテストに失敗してシグナルに気づくことがでます。この辺りは、実際にテストを書きながら体験してみないと良さに気付けないのではないでしょうか。
また、興味は持っているけどテストを書こうとしたら細かいところでどのように書いたらいいのかが分からずに、最初の2歩くらい進んだところで何となく手を止めて、「また今度やろう」という感じにないっているのではないでしょうか。
そんな方に個人的にはおすすめしたい1冊ではないかと思っています。
4〜5章
最近のフロントエンド開発では、コンポーネントと呼ばれる単位でUIの部品開発をすることが一般的になってきました。そのため、テストを考える際にもコンポーネント特有の処理などを考慮する必要があり、その点も初心者からするとハードルの1つではないでしょうか。
また、何らかの処理を行ったときにデータの状態が毎回同じではなく、回帰的テストがやりにくいけどどうしたらいいのだろう、毎回手作業でDBのデータを修正したほうがいいのだろうか？など、基本的なところでつまづいてしまうところはあります。
この書籍では、モックの活用やUIコンポーネントに関するテストについても、よく使うようなユースケースごとにサンプルコードも交えて紹介されていたので、走りながら実際に手を動かしながら理解を深められます。
8章
Storybookについても詳しく触れられていました。僕自身も内製化プロジェクトでStorybookを採用したものの、うまく使いこなせている感じしないため、そんな機能があったんだ！と気付かされることがいろいろとありました。
使い慣れるまではかなり時間がかかってしまうのですが、慣れてくるとかなり快適にコンポーネント開発が行えるようになるので、個人的にはこのようなツールを活用することはおすすめです。
9章
テスト関連の書籍を読んでいると、全てのアプリコードに均等に時間と労力を書けてテストコードを書くのはよろしくなく、できるだけ費用対効果が高いところから対応していくことが良いとされています。<
幸いフロントエンドは、見た目の状態で不具合が顕在化することがあるため、手軽にテストする手法があります。
それがビジュアルリグレッションテストと呼ばれるものなのですが、正常な状態をスナップショットとして持っておき、何か画面要素に変化があった時にシグナルとして検知してくれるような仕組みで、実際にコードを書く時にも数行くらいでかけるのでコスパいい方なのではないでしょうか(今風にいうとタイパでしょうか？)
また、ビジュアルリグレッションテストはコードの記載方法がほぼ同じため、コードジェネレーターなどを活用してファーストテストとして機会的に生成して動かしておくのもやり方の1つなのではないでしょうか。
ビジュアルリグレッションテストにも苦手なことはあり、動的な要素に関しては毎回差分として検知されるためノイズになってしまうことがあります。例えば、現在日時を表示するようなコンポーネントがあった場合には毎回差分として検知されます。ただ、対策の方法はありますが、詳しくは書籍を読んでみてください。このような感じでテストでよくあるつまづきポイントなどもケースごとに解説されています。
おわりに
個人的にもまだまだ生まれたての子鹿のように足元がおぼつかない感じで、フロントエンド開発をしばらくやることになりそうなので、テスト周りに関してはこちらの本にしばらくお世話になりそうです。
書き方に困った時にも大体のことはこの本に書いてあるので、よく見返すことがあります。
気になった方はぜひ読んでみてください。
