Javaユニットテストのデファクトスタンダード「JUnit」の解説書。モダンなJava開発においてユニットテストはいかなるアプリケーションを開発する場合にも欠かすことのできないプロセスです。本書では、ユニットテストの基礎からチーム開発でのユニットテストまで、達人プログラマーの実践的テクニックを明らかにします。さまざまなベストプラクティスからわかりやすい合い言葉が作られており、読者はユニットテストでの指針をすぐにマスターできるでしょう。避難は「おかし」、味付けは「さしすせそ」、ユニットテストは「FIRST」!
実践 JUnit
―達人プログラマーのユニットテスト技法
Jeff Langr, Andy Hunt, Dave Thomas 著、牧野 聡 訳
- TOPICS
- Programming , Java
- 発行年月日
- 2015年09月
- PRINT LENGTH
- 272
- ISBN
- 978-4-87311-730-0
- 原書
- Pragmatic Unit Testing in Java 8 with Junit
- FORMAT
- Print PDF EPUB
関連ファイル
目次
賞賛の声 序文 まえがき 第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 索引