単体テストの考え方・使い方を1年ちょっと前に買って、今頃になって少しずつマイペースで読んでいる。著者の考え方が自分とは違う部分があるけど、それはそれでおもしろい。
第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のキーノートくらい起きてられたらいいなと思っている。