読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第51回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。
- #50 V字モデルの深淵を覗き見た気分：UTPPPを読む（前編） - 勘と経験と読経
- #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる？ #デッドライン読書会 - 勘と経験と読経
- #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経
- #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経
- #46 「エンタープライズ設計」を再読した #デッドライン読書会 - 勘と経験と読経
今回取り上げるのは前回に引続きの「単体テストの考え方/使い方」（原題はUnit Testing Principles, Practices, and Petternsで、略すとUTPPPらしい）である。けっこうなボリュームがあるので2回に分けて読んでおり、前回最初の２部を読んでいるので、今回は後半の「第３部 統合（integration）テスト」「第４部 単体テストのアンチパターン」を読んでいる。
前半の感想はこちら
agnozingdays.hatenablog.com
昨年末に発売されて話題となり、冬休みの読書に最適などと言われていた本である。
なお本書は紙版に加えてKindle版もあるが、直販や達人出版会でコピーが可能なPDF版も販売されている。紹介されているコードを実際に動かしてみたい人などは、直販のPDFを買うことも検討されたし。
「単体テストの考え方/使い方」後半を読んだ感想
後半とくに「第３部 統合（integration）テスト」を読んでわかったのは、本書はデベロッパー（プログラマ）側のテストについて書かれている本のようだ、ということである（いまさらー！）。
ソフトウェアのテストについてはQA側のテストとデベロッパー側のテストがあると雑に整理してみると、本書が扱う「単体テスト」および「統合テスト」はQA側のテストではなくデベロッパー側が実施するものだ。だから本書の「第３部 統合（integration）テスト」で説明されるテストも、QA側のテストの匂いはほとんど感じられない（こうした理解しか出来ないのは自分がSIer脳だからかもしれないが）。
本書の冒頭付近で以下のような記述があるのだけれども、この理解を持って改めて読んでみるとなるほどと考えさせられる。
多くの書籍は単体テストの基本だけに目を向けており、それより先のことにはあまり踏み込んでいません。
（中略）
一方、本書は単体テストを作成できるようになったあとの段階にまで読者を導くようになっています。本書では、理想的な単体テストとはどのようなテストなのかについて正確で科学的な定義をし、この定義がいかに実用的で現実の世界を反映しているのかを提示しています。本書が望んでいることは、十分な数のテスト・ケースを用意したのにもかかわらず、なぜ、プロジェクトが期待した結果を得られないのか、そして、そのことを修正するためには何をすればよいのか、ということを理解する手助けになることです。
単体テストの考え方/使い方 1.1 単体テストの現状、より
というわけで「第３部 統合（integration）テスト」で説明されるのはQA側が実施する統合テストではなく、デベロッパーが実施するより高度な単体テスト（と書くと語弊があるが詳しくは書籍をご覧いただきたい）なのだ、という事である。うーん、なるほどねー。
改めて、単体テストについて考える
この本を読むことによって、だいぶ単体テストの解像度が上がった気がする。有名なt_wadaさんの以下のスライドのわかりみが増したような気もする
speakerdeck.com
そして解像度が上がったことにより、反省もいっぱいあるのである
いろいろと気づきの多い良い読書であった
