📝
読書メモ：単体テストの考え方/使い方
前提
- 当記事の筆者はE2Eテスト（システムテスト）を専門とするテスター・QAで、実務でコードを読み書きした経験はない。ないのだが、テストと名前がつくものには興味関心が強い。
- 前述の通り実務でコードを読み書きしていないので、この記事に単体・結合テストを実装するにあたって有意義な知見やスマートな要約はない。あくまで『実務でコードを読み書きしない人がこの本を読んで、どういう感想を持ったか』であることをご留意いただきたい。
概要
第1章：なぜ、単体テストを行うのか？
- 『網羅率(coverage)は目安として活用できるが、固執すべきではない』という言説の裏づけとして、『何も確認していないコードでも網羅率は上がるので、網羅率が100%であっても効果がない場合がある』ということを具体例・たとえ話を通じて理解できる。
第2章：単体テストとは何か？
- 古典学派とロンドン学派の違い、単体テストの定義、良いテストの条件についての説明が理解しやすかった。特に印象的だったのは『実装の詳細ではなく、最終的な結果を確認する』という点だ。E2Eテスト・システムテストでは手動・自動どちらでも意識している点だが、単体テストでも同じなのだと知って驚いた。
第3章：単体テストの構造的解析
- この章は具体的なコードの話が多く、個人的に読解が難しかった。ただ、『テスト内でif文を使うべきではない』という点はPlaywrightと共通していてわかりやすかった。if文が必要ということは複数の結果を確認しているということだ。テストの主題を理解しづらくなり、実施にも時間がかかるのでデメリットが大きい。
第4章：良い単体テストを構成する4本の柱
- 『退行(regression)に対する保護』『リファクタリングへの耐性』『迅速なフィードバック』『保守のしやすさ』の4点。保守のしやすさは欠かすことができないので、残りの3点のトレードオフに目を向ける。
- 『退行に対する保護』は偽陰性(バグがあるのに検出できない) を抑えられていること。『リファクタリングへの耐性』偽陽性(バグではないのに失敗する) 抑えられていること。これら2点をまとめると、『バグとそれ以外を適切に見分けられていること』ともいえる。
- 一般に E2Eテストはリファクタリングへの耐性と退行に対する保護を持つが、迅速なフィードバックは得られない。実装の詳細ではなく結果を見ているので、バグとそれ以外を見分けやすい[1]が、自動でも手動でも原理上実施に時間がかかるからだ。
- リファクタリングへの耐性と迅速なフィードバックを持つが、退行に対する保護がない=バグを検出する見込みがないテストは取るに足らないテストといわれる。テスト対象のコードと同じロジックを実行するだけのテストが該当する。
- 迅速にフィードバックを得られるがリファクタリングに耐性がない=偽陽性が頻発する=壊れやすいテストも問題だ。リファクタリングのたびに起きるエラーはいずれ無視され、自動テストの意味がなくなる。ふるまいではなく実装の詳細に着目しているテストが該当する。
- すべてを完璧に満たす単体テストは作れない。また、リファクタリングへの保護がないと自動テスト自体の価値がなくなってしまう。よって、『退行に対する保護』と『迅速なフィードバック』の2点を調整してテストを作る。
第5章以降
- これ以降は内容を理解できなかったので割愛。中途半端な記事になってしまうことをご容赦いただきたい。
- ゲームでいう『レベルが上がると行けるようになる場所』だと思っているので、経験・知識を積んでから読み直したい。
まとめ
- 単体テスト・結合テストの概要やE2Eテストとの違いを知れてよかった。私と同じような『コードを読み書きしないが、テストに強い関心のある方』は一読してみてはいかがだろうか。
書籍購入URL
-
十分なドキュメントや知識がある前提。"何が正しい"かを判断する材料がなければ、偽陰性・偽陽性のリスクは高まる ↩︎
Discussion