【感想・ネタバレ】単体テストの考え方/使い方のレビュー

Vladimir Khorikov / 須田智之

※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。

質の高いテストを行い、ソフトウェアに価値をもたらそう！

単体（unit）テストの原則・実践とそのパターン ― プロジェクトの持続可能な成長を実現するための戦略について解説。

優れたテストを実践すれば、ソフトウェアの品質改善とプロジェクトの成長に役立ちます。逆に間違ったテストを行えば、コードを壊し、バグを増やし、時間とコストだけが増えていきます。生産性とソフトウェアの品質を高めるため、優れた"単体テスト"の方法を学ぶことは、多くの開発者とソフトウェア・プロジェクトのために必須といえるでしょう。

本書“単体テストの考え方/使い方”では、単体テストと統合テストの定義を明確にします。そして、どのようなテストに価値があるのかを学び、どのテストをリファクタリング、もしくは削除するのか、ということについて考え、そのことがプロジェクトの成長にどう繋がるのかを見ていきます。
C#のコード例で解説しますが、どの言語にも適用できる内容です。

Manning Publishing: Unit Testing Principles Practices and Patterns の翻訳書。


目次
第1部: 単体（unit）テストとは？
第1章: なぜ、単体テストを行うのか？
第2章: 単体テストとは何か？
第3章: 単体テストの構造的解析

第2部: 単体テストとその価値
第4章: 良い単体テストを構成する4本の柱
第5章: モックの利用とテストの壊れやすさ
第6章: 単体テストの3つの手法
第7章: 単体テストの価値を高めるリファクタリング

第3部: 統合（integration）テスト
第8章: なぜ、統合（integration）テストを行うのか？
第9章: モックのベスト・プラクティス
第10章: データベースに対するテスト

第4部: 単体テストのアンチ・パターン
第11章: 単体テストのアンチ・パターン

Vladimir Khorikov（ウラジーミル・コリコフ）：ソフトウェア・エンジニア、Microsoft MVP受賞者、単体テストに関するブログの執筆や講座を受け持ったりしている。
須田智之：フリーランスエンジニア、IT分野の記事や書籍も執筆している。執筆した書籍に『RxJavaリアクティブプログラミング』、翻訳書に『セキュア・バイ・デザイン』がある。

[ブクログ · ★★★★★]

初めてテストについてちゃんと学んだ。少しレベルアップした気がする。このような良い本を入手できてラッキーだった。

リファクタリングとテストは切り離せない、テストがなければリファクタリングは成り立たない、そのように言われる理由がよく分かった。

アプリケーションの関心を、ドメインモデル、アプリケーションサービス、プロセス外依存に分離することが徹底されている。これが前提であり、このアーキテクチャに従うことで初めてテストが良い結果をもたらすようになる。このアーキテクチャはそんなに斬新なものでも窮屈なものでもなくて、基礎的なレベルの話だと考えたほうが良い。通常のアプリケーションなら無意味に逆らったり軽視するものでもない。ヘキサゴナルアーキテクチャと名前がつけられている。比較に関数型アーキテクチャについても解説がある。

[ブクログ · ★★★★★]

いわゆるUnitテストに対する考え方と実践について詳細に分析を行っている一冊。終盤においては、Unitテストだけでなく、Integrationテストにも分析を行っていて、ソフトウェアのテストについてどのように設計して実装すれば良いかを記している。モックについての考え方やデータベースに対するテストの考え方も参考になる。また、どうしてテストが壊れるのかについての考察も勉強になる。サンプルがC#で書かれているので、C#に慣れていない人にとってはとっつきにくいかもしれない。

[ブクログ · ★★★★★]

# ユニットテストとの向き合い方を改めて考えさせられた、テストの聖典

## 面白かったところ

- `ユニットテスト = クラスのテスト` という誤謬を是正するような内容となっている点

- ロンドン学派・デトロイト学派などのテストの宗派があるもののそれぞれの特徴と使い方を学べる点

- 用いる依存によって境界の引き方を変える手法が学べる点

## 微妙だったところ

特になし

## 感想

ユニットテストとは何なのか、深く考えたこともなかった。

モジュールの細かい動作を担保するために書き、いかにもイイコトをしているように見えるテストコードも、よくよく見てみたら意味のあるテストと意味のないテストに分類される。

細かく挙動を担保しなければならないモジュールのテストは数で言えばそう多くはない。

それよりも、I/Oを意識したユースケースや仕様の担保ができるテストが大事だなあと改めて実感した。

モックは使い所を選ばないといけないし、モックを使えば使うほど手が掛かるテストになる。

正直、ここ数年で読んだ技術書の中で度肝を抜かれた一冊。若手・中堅のソフトウェアエンジニアはぜひ読むべき。

[ブクログ · ★★★★★]

統合テストに関する指針を解説している書籍に初めて出会った。統合テストの章を読むだけでも非常に有用だと思う。

[ブクログ · ★★★★☆]

読むのに時間掛かりました。笑
単体テストって、なかなか指針がないところもあったりで、実装者任せになることもあると思う。適切なテストダブルの利用は大事。また、テストコードを実装することでプロダクトコードのリファクタリングへの警鐘になったり、テスト駆動設計に通じるものはある。とにかくも、和訳なので何回も読み直さないとではある。

[ブクログ · ★★★☆☆]

会社の輪読会にて。特に前半の単体テストについての記述は興味深かった。「モック」と「スタブ」はあまり意識して使い分けていなかったので、知識のアップデートになった。