TestHarnessを使った雑感

概要

Angular のアドベントカレンダーに空きがあったので直前だしポエム寄りでも許されてくれという気持ちで、遅ればせながら最近 TestHarness を使ってみた感想をざっと書きたいと思います。なんだかんだまだ使ったことないな〜という人が次にテストを書く機会を得た時に使ってみようかな？とちらっとでも思ってもらえれば本望です。ただの感想なので Harness のちゃんとした説明はしません。

Disclaimer

いつものです。
この記事を執筆現在私は Google で働いています。記事内で Google のプロダクトについて言及するため明確に所属を記載していますが、私は記事内に登場するプロダクトについて特別詳しいわけではありません。１ユーザーが書いた記事としてお楽しみください。

背景

もともと Angular にあまり詳しくない人(本人談)がやっていたサイドプロジェクトのフロントを触らせてもらうことになりました。Angular Material を使っているので、噂の TestHarness を試す時が来たんじゃないか…！？と使い始めてみた次第です。既存のテストには Harness は使われていませんでした。(そもそも Harness の存在を知らなかったらしいです)

要素が釣りやすくなる

過去にテストを書いていたときは Angular Material より自家製コンポーネントライブラリが中心でしたが、テストするときテストしたい内容を釣るのにちょっと苦労していた覚えがあります。そのコンポーネントの中の構造をよく知らないとうまく釣れないとか。指定したテキストが思った要素の直下になかったり、そもそも何で釣れば良さそうかを判断するのに中を見に行ったり。

TestHarness を使うと、例えば Angular Material の場合、API に乗っかってるだけで mat-button のような特定の要素を絞ってくれます。そこから更に 1 つのボタンに絞る時も、API に乗っかってテキストや id などでセレクタを指定すればよしなに絞り込んでくれるので、中の作りとかを一切気にする必要がありません。「〇〇と言うラベルの mat-button」と言うことさえわかっていれば、スムーズに要素を釣ることができます。

テストが壊れにくくなる

これは元のテストの書き方も関係しているんですが、おそらく今まで書いたように要素を釣るのが少し大変なのもあってか、結構な数の要素がタグで全部取得 → 配列の index で指定と言う方法で書かれていました。これだと、例えばその index の前に同じ種類の要素を追加した時に拾われている要素が変わってしまい、関連するテストが全部落ちるため、都度全部修正しなければいけません。

TestHarness を使うようになってからは Material の要素の種類 + α (テキストなど) で要素を指定するようになったので、こういうパターンのテストの壊れ方がかなり減ったように思います。

イベントを発生させるのも楽

TestHarness にはコンポーネントに対応するイベントの API も準備されているので、click はもちろん例えば mat-menu ならclickItem のように直感的にイベントを発生させることができます。
click だけだったら正直そこまで恩恵ないかもしれませんが、メニューを開いて更に子メニューを選択するとかになってくると、自分でどうやって頭の中にある操作と同等のイベントを起こすか考えるのと API ドキュメント見て呼び出すだけだと結構テスト書く体験が変わってくるんじゃないかと思います。

まとめ

ライブラリのユーザーとしては、Angular Material を使っていてテストを書くなら絶対 Harness 使った方が楽だなと感じています。かつて自家製コンポーネントライブラリをやっていた時を振り返ると、テストを書く人が多くてユーザーも多いなら、少し手間はかかってしまいますが費用対効果が良さそうなのでできるだけ準備してあげたいなと思います。(でも当時は使う側がテストまで手の回っていないところばかりだったのでおそらく意味は無かったでしょう…)

最後に、これを読んでもしも使ってみようかなと思ってくださった方がいる場合は、公式ドキュメントのガイドがわかりやすいのでぜひご参照ください。それでは良きテストライフと良き冬を ❄️