単体テストの考え方・使い方をマイペースで読んでいる(第4章)

単体テストの考え方・使い方を1年ちょっと前に買って、今頃になって少しずつマイペースで読んでいる。著者の考え方が自分とは違う部分があるけど、それはそれでおもしろい。

book.mynavi.jp

第4章を読んだ

昨日いちど第4章を読んで、今日ももういちど読み直した。この章を読み直した理由は、あんまりしっくりこなかったから。でも、別にしっくりこなかった部分については今日は書かない。今日はただのメモ。

この章では、良い単体テストを構成する4つの柱について書かれている。

  • リグレッションに対する保護
  • リファクタリングへの耐性
  • 迅速なフィードバック
  • 保守のしやすさ

これ自体はとてもよく分かる。単体テストというか、自動テストを考えるときに考えるなぁって気がする。

こんな感じかなぁ

以下、ぼーっとこんな感じかなぁって思った。

UT IT E2E
リグレッションに対する保護
リファクタリングへの耐性
迅速なフィードバック
保守のしやすさ

んー。書きながら「いや、こういう分類で書くのむずいな」ってなった。した2つの「スピード」と「保守のしやすさ」は簡単だけど。うえ2つが難しいな。

リグレッションに対する保護

UTを◯、ITを◎、E2Eを◯にしたのだけど。

違いは「どれくらいリグレッションを検知できるか」じゃなくて「どの範囲に対するリグレッション検知か」だな。

  • UTだと、単体の検知はできても、それらをつないだ全体としての検知はしづらい。
  • E2Eだと、全体をつないだ検知はできるけど、こまかな動きのリグレッションの検知は難しい。
  • ITが、その中間で、ある程度つないだふるまいを、ある程度のスピードで検知できる。

って感じかなぁ。

だから、UTで単体のパーツの動作確認はしておいて、ITでそれらをつないだ動作確認をしておいて、E2EではITで確認できないような全体をつないだ部分の動作確認にしぼる。のがいいかなと思っている。

リファクタリングへの耐性

これもITを◎、UTとE2Eを◯にしてみた。

  • そんなに複雑じゃないWeb APIならITレベルでテストをしておくと、テストを書き換えずに内部を変更できる。
  • UTだと、それよりも狭い範囲のリファクタリングになる。とはいえ、単体のロジックのリファクタリングができるのもすごくいいので、そういう意味ではUTは◎かもしれない。
  • E2Eは、リファクタリングというよりはリアーキテクチャしたときにチェックできて嬉しいなってくらいかな。

だから

この2つに関しては、UT < IT < E2E なので、テストピラミッドのようになるのがいいなって思う。

  • 迅速なフィードバック
  • 保守のしやすさ

そして、この2つに関しては、UTとITとE2Eそれぞれで担当する範囲が違っていて、できるだけUTでカバー、ITで中間を見て、E2Eは最小限で全体を見るかな。

  • リグレッションに対する保護
  • リファクタリングへの耐性

そしてこの本には「保守性以外の3つは同時には満たせない」って書いてあるけど、自分はそこがしっくりきていない。とはいえ、面白かった。

続き

の第5章からは、また気が向いたら読もう。もしかしたら↑のような話は、5章以降で出てくるのかもしれない。今日はReact Confのキーノートくらい起きてられたらいいなと思っている。