単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略

備考

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

関連ページ

• サポートサイト　https://book.mynavi.jp/supportsite/detail/9784839981723.html
• 原著サイト　https://www.manning.com/books/unit-testing
• サンプルコード（C#）　https://www.manning.com/downloads/2014

目次

第１部　単体（unit）テストとは
第1章 なぜ、単体（unit）テストを行うのか？
1.1 単体テストの現状
1.2 なぜ、単体テストを行うのか？
1.3 網羅率（coverage）とテスト・スイートの質との関係
1.4 何がテスト・スイートの質を良くするのか？
1.5 本書から学べること

第2章 単体テストとは何か？
2.1 単体テストの定義
2.2 古典学派およびロンドン学派が考える単体テスト
2.3 単体テストにおける古典学派とロンドン学派の違い
2.4 古典学派およびロンドン学派における統合（integration）テスト

第3章 単体テストの構造的解析
3.1 単体テストの構造
3.2 単体テストのフレームワークについて
3.3 テスト・ケース間で共有するテスト・フィクスチャ（test fixture）
3.4 単体テストでの名前の付け方
3.5 パラメータ化テストへのリファクタリング
3.6 確認（Assert）フェーズの読みやすさの改善

第2部　単体テストとその価値
第4章 良い単体テストを構成する4本の柱
4.1 良い単体テストを構成する4本の柱
4.2 退行（regression）に対する保護とリファクタリングへの耐性との関係
4.3 迅速なフィードバックと保守のしやすさ
4.4 理想的なテストの探求
4.5 ソフトウェア・テストにおけるよく知られた概念

第5章 モックの利用とテストの壊れやすさ
5.1 モックとスタブの違い
5.2 観察可能な振る舞い（observable behavior）と実装の詳細（implementation detail）
5.3 モックの利用とテストの壊れやすさとの関係
5.4 振り返り: 単体テストの古典学派とロンドン学派の違い

第6章 単体テストの3つの手法
6.1 単体テストの3つの手法
6.2 単体テストの3つの手法の比較
6.3 関数型アーキテクチャについて
6.4 関数型アーキテクチャおよび出力値ベース・テストへの移行
6.5 関数型アーキテクチャの欠点

第7章 単体テストの価値を高めるリファクタリング
7.1 リファクタリングが必要なコードの識別
7.2 単体テストに価値を持たせるためのリファクタリング
7.3 プロダクション・コードの種類に基づく効果的な単体テストの作成
7.4 コントローラにおける条件付きロジックの扱い
7.5 結論

第3部　統合（integration）テスト
第8章 なぜ、統合（integration）テストを行うのか？
8.1 統合（integration）テストとは？
8.2 どのようなプロセス外依存をモックに置き換えるべきか？
8.3 どのように統合（integration）テストを行うのか？
8.4 インターフェイスを使った依存の抽象化
8.5 統合テストのベスト・プラクティス
8.6 ログ出力に対するテスト
8.7 結論

第9章 モックのベスト・プラクティス
9.1 モックの価値を最大限に引き出す方法
9.2 モックのベスト・プラクティス

第10章 データベースに対するテスト
10.1 データベースをテストするのに必要な事前準備
10.2 データベース・トランザクションの管理
10.3 テスト・データのライフ・サイクル
10.4 テスト・コードの再利用
10.5 データベースを使ったテストに関するよくある疑問
10.6 結論

第4部　単体テストのアンチ・パターン
第11章 単体テストのアンチ・パターン
11.1 プライベートなメソッドに対する単体テスト
11.2 プライベートな状態の公開
11.3 テストへのドメイン知識の漏洩
11.4 プロダクション・コードへの汚染
11.5 具象クラスに対するテスト・ダブル
11.6 単体テストにおける現在日時の扱い
11.7 結論