勉強会を開催したので、そのときに話した内容を書く。UtilsVue.jsを採用しているので、それらを用いたテストコードを掲載しているが、大半の内容は上記以外のスタックを用いたテストにも当てはまるものだと思う。「読みやすさ」を重視するのか、その背景について説明する。3つを備えているものがそれにあたると考えている。3つが等しく重要だとは考えていない。信頼できるものであることが最重要だと考えている。フロントエンドチームでは、何をテストするか?について既に吟味されており、テストガイドラインという名のドキュメントが存在している。チームメンバー全員の認識が揃っている(ここがすごく重要で、認識が揃っているとコードレビューで「ここはテストすべきでは?」とかいうコメントをしなくて済む)したがって、開催した勉強会ではこのあたりの話は割愛した。崩れに気付けるようにしようとか複雑度の低いミューテーションとかはテストを書かなくてよいよねとかみんな、このあたりのドキュメントは読んでおこうねといったようなことがまとめられている。書きやすさテストの読みやすさと書きやすさのどちらがより重要かについては、実装のコードと同様に「書く回数よりも読まれる回数のほうが圧倒的に多いから」という理由で、読みやすさのほうが重要だと考える。なくても、経験上、それほど困らない。仕様の変更などがあって、それをコードに反映させる場合、実装のコードでは反映漏れがあれば、そこがすなわちバグとなるが、テストコードに反映漏れがあったところで、そのテストがこけるだけなので、漏れに気付いて修正するだけで済む。すると、急激にテストが読みにくくなる。メソッドの中だけを見てもテストの意図と内容を把握できず、理解に余計な時間がかかったりする。したがって、読みやすさと書きやすさが競合する場合には、読みやすさのほうを重視すべきであり、タイトルに「読みやすさを重視した」と入れているのはそのためである。テストの実行速度は?ところで、テストの実行速度について、これがあまりにも遅くて時間がかかると、開発速度に影響してくる。39秒であり、まだテストの実行時間が問題になっているフェーズではない。したがって、テストの実行速度については重視しない。以上のような背景があり、今回、書きやすさや実行速度よりも、読みやすさを重視したテストの書き方をお伝えする。メソッドを使う典型的なケースは、下記のようにテストコードが重複しているときだと思う。