読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第50回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。
- #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる？ #デッドライン読書会 - 勘と経験と読経
- #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経
- #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経
- #46 「エンタープライズ設計」を再読した #デッドライン読書会 - 勘と経験と読経
- #45 パタヘネを読む４（付録Ａ、Ｂ） #デッドライン読書会 - 勘と経験と読経
さて、今回取り上げるのは「単体テストの考え方/使い方」（原題はUnit Testing Principles, Practices, and Petternsで、略すとUTPPPらしい）である。けっこうなボリュームがあるので4つの部のうち最初の２部すなわち、「第１部 単体（unit）テストとは」「第２部 単体テストとその価値」をまず読んでいる。
昨年末に発売されて話題となり、冬休みの読書に最適などと言われていた本である。
残念ながら年末年始は他の本を読むに忙しかったので、年明けから読み始めている。
なお本書であるが紙版に加えてKindle版もあるが、直販や達人出版会でコピーが可能なPDF版も販売されているようだ。紹介されているコードを実際に動かしてみたい人などは、直販のPDFを買うのが良いかもしれない。
「単体テストの考え方/使い方」前半を読んだ感想
本書はタイトルにこそ単体テストという単語が書かれてはいるが、実際には単体テストを鏡として、次のような概念が学べるような内容となっている（後半を読んでいないのでリストは増えるかもしれない）
- ソフトウェア開発ライフサイクル全般
- ソフトウェアテスト戦略、テストピラミッド
- 保守性
- 変更のしやすいソフトウェアとは何か
- ヘキサゴナルアーキテクチャおよび関数型アーキテクチャ
- 良い設計とリファクタリング
- 統合テスト
- 単体テストのアンチパターン
類書だと抽象的になりがちなアーキテクチャや設計に関するトピックが、範囲は限定的ではあるが実装と単体テストという具体例を用いて説明されるのが、とてもわかりやすいと感じている。良い本だと思う。
本書を手に取った読者の中には、もしかしたら、本書のことを単体テストによるバグの見つけ方やテスト・データの作り方などについて書かれたものだと思っている人がいるかもしれません。しかしながら、本書は、どちらかと言えば、単体テストがどのようにソフトウェアの継続的な開発を助けるのか、そして、どのように技術的負債として開発の妨げとならないようにするのか、ということを意識して書かれたものとなっています。そのため、単体テストについてほとんど経験のない読者からすると、もしかしたら、本書は思っていたのと違う本なのかもしれません。
「単体テストの考え方/使い方」、「翻訳者より」から抜粋
本書の前半から学んだ内容の覚え書き
第１部 単体（unit）テストとは
- 単体テストに関する議論は「単体テストを書くべきか？」から「良い単体テストを書くとはどういう意味なのか？」に移ってきており、混乱を生じている
- 本書はエンタープライズ・アプリケーションにこそ最大限に活用できる
- （⇒自分にとっての重要ポイント！）
- エンタープライズ・アプリケーションとは何か？
- ビジネス・ロジックが非常に複雑であること
- プロジェクトの生存期間が長いこと
- 適切な量のデータしか扱わないこと（ビッグ・データなどは扱わない）
- パフォーマンスへの要求はあまり高くないこと（膨大な数のユーザがいるわけではない）
- ソフトウェア・エントロピー
- 網羅率の計測方法、使い方、課題、開発者が網羅率の特定の値に縛られることは害であるということ
- 単体テストの定義
- 「単体（unit）と呼ばれる少量のコードを検証する
- 実行時間が短い
- 隔離された状態で実行される
- 単体テストにおける古典学派とロンドン学派
- （⇒このトピックは本書のネタ（ジョーク）のようにも感じられるのだけれどもどうなんですかね）
- SUT（System Under Test）
第２部 単体テストとその価値
- プログラミングにおいて、コードは資産ではなく、負債であるということ
- （⇒技術的負債論は多々あれど、コードそのものを負債と言い切っているのは珍しいような印象をもったがどうだろう）
- 良い単体テストを構成する４本の柱
- 退行（regression）に対する保護
- リファクタリングへの耐性
- 迅速なフィードバック
- 保守のしやすさ
- 単体テストにおける偽陽性（false positive）と偽陰性（false negative）
- ヘキサゴナル・アーキテクチャと単体テスト
- ヘキサゴナル・アーキテクチャと関数型アーキテクチャの違い
- 出力値ベース・テストと状態ベース・テスト、コミュニケーション・ベース・テスト
- プロダクション・コードの分類
- コードの複雑さ／ドメインにおける重要性 と
- 協力者オブジェクトの数
というわけで、後半に続く（まだ読んでいないので2週間後くらいに書く）
