賞賛の声
序文
まえがき
第I部　ユニットテストの基礎
1章　初めてのJUnitテスト
1.1　ユニットテストを作成する理由
1.2　JUnitの基礎（テストを作成し、成功させる）
1.2.1　プロジェクトの設定
1.2.2　JUnitテストの構成要素
1.2.3　JUnitの実行
1.3　Arrange-Act-Assert
1.4　テストは本当に行われているのか
1.5　まとめ
2章　JUnitの実践的な利用
2.1　テスト対象を理解する（Profileクラス）
2.2　どんなテストが可能か検討する
2.3　1つ目のパスへのテスト
2.4　2つ目のパスのテスト
2.5　@Beforeメソッドを使った初期化
2.6　残りの作業
2.7　まとめ
3章　さまざまなアサーション
3.1　JUnitでのアサーション
3.1.1　assertTrue
3.1.2　assertThat（何かと何かが等しいことを示す）
3.1.3　重要なHamcrestマッチャー
3.1.4　浮動小数点数の比較
3.1.5　アサーションの説明
3.2　例外を扱う3つの考え方
3.2.1　シンプルな方法（アノテーションの利用）
3.2.2　古い方法（try/catchとfail()）
3.2.3　新しい方法（ ExpectedExceptionルール）
3.2.4　例外的な状況での例外
3.3　まとめ
4章　テストの構成
4.1　AAAに基づいた一貫性の実現
4.2　ふるまいのテストとメソッドのテスト
4.3　テストと対象のコードの関係
4.3.1　テストと対象のコードの分離
4.3.2　privateなデータの公開、privateなふるまいの公開
4.4　1つの目的に特化したテストの価値
4.5　ドキュメントとしてのテスト
4.5.1　一貫性のある名前
4.5.2　意味のあるテスト
4.6　@Beforeと@Afterに関する補足（初期化と後処理）
4.6.1　@BeforeClassと@AfterClass
4.7　テストと緑のバーの重要性
4.7.1　テストの所要時間を縮める
4.7.2　テストを無視する
4.8　まとめ
第II部　合い言葉で覚えるユニットテスト
5章　FIRST（よいテストとは）
5.1　よいテストはFIRSTである
5.2　Fast（迅速）
5.3　Isolate（テストを隔離する）
5.4　Repeatable（繰り返し可能）
5.5　Self-Validating（自律的検証）
5.6　Timely（適切なタイミングでテストする）
5.7　まとめ
6章　Right-BICEP（テストの対象）
6.1　Right（結果の正しさ）
6.2　Boundary（境界条件）
6.2.1　CORRECTに従った境界条件の設定
6.3　Inverse（逆の関係をチェックする）
6.4　Cross-check（別の方法でチェックする）
6.5　Error（エラーを強制的に発生させる）
6.6　Performance（パフォーマンスの特性）
6.7　まとめ
7章　CORRECT（境界条件の扱い）
7.1　Conformance（適合）
7.2　Ordering（順序）
7.3　Range（範囲）
7.3.1　制約をチェックするマッチャー
7.3.2　制約をチェックする埋め込みのメソッド
7.4　Reference（参照）
7.5　Existence（存在）
7.6　Cardinality（要素数）
7.7　Time（時間）
7.8　まとめ
第III部　より大きな設計の全体像
8章　クリーンなコードをめざすリファクタリング
8.1　リファクタリングとは
8.1.1　リファクタリングを行うべき時
8.1.2　メソッドを抜き出す（次善のリファクタリング）
8.2　メソッドの置き場を決める
8.3　リファクタリングの自動実行と手動実行
8.4　過剰なリファクタリングの是非
8.4.1　メリット（明確で個別のテストが可能）
8.4.2　パフォーマンス面の不安
8.5　まとめ
9章　より大きな設計上の課題
9.1　ProfileクラスとSRP
9.2　新しいクラスの抜き出し
9.3　コマンドとクエリの分離
9.4　ユニットテストを保守するコスト
9.4.1　失敗を防ぐ方法
9.4.2　壊れたテストの修正
9.5　その他の設計上のポイント
9.6　まとめ
10章　モックオブジェクト
10.1　テストでの課題
10.2　厄介なふるまいをスタブで置き換える
10.3　テスト向けの設計変更
10.4　スタブを賢くする（パラメーターの検証）
10.5　モックツールを使ったテストの簡素化
10.6　注入ツールを使った簡素化
10.7　モックを利用する際のポイント
10.8　まとめ
11章　テストのリファクタリング
11.1　現状のテスト
11.2　「テストの臭い」その1（不必要なコード）
11.3　「テストの臭い」その2（アブストラクションの欠如）
11.4　「テストの臭い」その3（無関係な情報）
11.5　「テストの臭い」その4（肥大化したコンストラクタ）
11.6　「テストの臭い」その5（複数のアサーション）
11.7　「テストの臭い」その6（不必要な詳細さ）
11.8　「テストの臭い」その7（誤解を招く構成）
11.9　「テストの臭い」その8（暗黙の意味づけ）
11.10　テストの追加
11.11　まとめ
第IV部　より大きなテストの全体像
12章　テスト駆動開発
12.1　TDDの主なメリット
12.2　シンプルなコードから始める
12.3　2回目の追加
12.4　テストのクリーンアップ
12.5　3回目の小さな追加
12.6　複数の回答への対応（設計の寄り道）
12.7　APIの拡張
12.8　最後のテスト
12.9　ドキュメントとしてのテスト
12.10　TDDの周期性
12.11　まとめ
13章　テストが難しい事柄
13.1　マルチスレッドのコードのテスト
13.1.1　物事はシンプルに
13.1.2　プロフィールのマッチング
13.1.3　アプリケーションロジックの抜き出し
13.1.4　スレッドのロジックをテストするための再設計
13.1.5　スレッド関連のロジックのテスト
13.2　データベースのテスト
13.2.1　QuestionControllerの活躍
13.2.2　データの問題
13.2.3　クリーンな状態でのデータベーステスト
13.2.4　QuestionControllerのモック化
13.3　まとめ
14章　プロジェクトでのテスト
14.1　開発の加速
14.2　共通の理解を深める
14.2.1　ユニットテストの基準を定める
14.2.2　レビューを通じて基準への準拠を促進する
14.2.3　ペアプログラミングでのレビュー
14.3　継続的インテグレーションとの統合
14.4　カバレッジ
14.4.1　望ましいカバレッジの値
14.4.2　100パーセントのカバレッジは本当に望ましいのか
14.4.3　カバレッジの意義
14.5　まとめ
付録A　IntelliJ IDEAとNetBeansでのJUnitのセットアップ
A.1　IntelliJ IDEA
A.2　NetBeans
索引