本書では、「いかにしてテスト駆動開発をプロジェクトに適合させればよいか」「どこから手を付けるか」「ユニットテストとエンドツーエンドテストを両方とも書かねばならないのはなぜか」「テストに開発を“駆動”させるとはどういう意味か」といった、プロジェクトで遭遇しがちな疑問や混乱に道筋を与え、ソフトウェアを“肥大化”ではなく“育てる”方法を伝授する。プロフェッショナルを目指す、あるいは自認する開発者必読の書です。
まえがき
推薦のことば
序文
著者について
翻訳者について
『実践テスト駆動開発』への賛辞
学習プロセスとしてのソフトウェア開発
フィードバックは欠かせないツールである
変化を支えるプラクティス
テスト駆動開発ひとめぐり
全体像
エンドツーエンドでテストする
テストのレベル
外側の質と内側の質
オブジェクトの網の目
“値”と“オブジェクト”
メッセージに従うこと
命じよ、訊ねるな
しかし、時には訊ねることもある
協力しあうオブジェクトのユニットテスト
モックオブジェクトを用いてTDD をサポートする
すでに知っているなら飛ばしても大丈夫
JUnit 4 の簡単な紹介
Hamcrest のマッチャーとassertThat()
jMock2：モックオブジェクト
序論
まずは動くスケルトンをテストする
動くスケルトンのかたちを定める
フィードバックの源泉を構築する
不確かなことを早めに明らかにする
序論
フィーチャの実装を受け入れテストから始める
進捗を測るテストとリグレッションを検出するテストを区別する
もっともシンプルな正常ケースからテストを始める
読みたいテストを書く
テストが失敗するのを確認する
入力から始め、出力に向けて開発する
振る舞いのユニットテストを行えメソッドをテストするのではない
テストの声を聴く
サイクルを回す
導入
保守を考えて設計する
内部構造vs. ピア
AND やOR、BUT は禁止
オブジェクトピアのステレオタイプ
コンポジットは構成要素の総体よりもシンプルにせよ
コンテキストからの独立
適切な情報を隠蔽する
自分たちなりの見方
テストファーストは設計にどう役立つか
分類よりもコミュニケーションを
値型
オブジェクトはどこから来るのか?
インターフェイスを用いて関係性を特定する
インターフェイスもリファクタリングする
オブジェクトを複数組み合わせてシステムの振る舞いを記述する
抽象レベルのプログラミングを組み上げる
クラスはどう考えればよいか?
導入
モックするのは自分の持っている型だけ
インテグレーションテスト内でアプリケーションオブジェクトをモックする
最初から始める
オークションと通信する
安全に作る
現実はこうはいかない
スケルトンの全貌を明らかにする
一番最初のテスト
いくつかの最初の選択
テスト装置を構築する
テストを失敗させ、そして、通るようにする
必要最小限
マーケットへの参入
入札のテスト
AuctionMessageTranslator
価格メッセージを解析する
作業を終わらせる
AuctionSniper を導入する
入札メッセージを送信する
実装を整える
意思決定を後回しにする
創発的設計
まずは失敗するテストから
入札者については誰が知っているのか?
スナイパーのやるべきことは他にもある
スナイパーに状態をいくつか加える
スナイパーが落札する
安定して進捗させる
より現実的な実装
価格の詳細を表示する
スナイパーイベントをシンプルにする
最後までやり切る
最後の仕上げ
所見
複数の商品のためのテスト
ユーザーインターフェイスから商品を追加する
所見
ロールを見つける
チャットを抽出する
接続を抽出する
SnipersTableModel を抽出する
所見
もっと役に立つアプリケーション
値段が上がりすぎたら入札をやめる
所見
うまくいかなかったらどうする?
エラーを検知する
エラーを表示する
スナイパーの接続を切る
エラーを記録する
所見
序論
オブジェクトのモックを作りたいが（裏技を使わないと）置き換えられない
ユニットテストでもプロダクションコードと同じテクニックを使って依存関係を排除する243 ログ出力はフィーチャ
具象クラスのモック
値をモックしない
肥大化したコンストラクタ
混乱したオブジェクト
多すぎる依存関係
多すぎるエクスペクテーション
（きちんと声を聴いたときに）テストが教えてくれること
序論
フィーチャを表すテスト名
標準的なテストの構成
テストコードの合理化
アサーションとエクスペクテーション
リテラルと変数
序論
テストデータビルダー
よく似たオブジェクトの作成
ビルダーの組み合わせ
ファクトリーメソッドによるドメインモデルの強調
重複の削除の実例
コミュニケーションが第一
失敗させる設計
小さく、焦点が絞られ、適切な名前がつけられたテスト
説明的なアサーションメッセージ
マッチャーによる詳細の強調
自己説明的な値
仕込まれたことが明らかな値
トレーサーオブジェクト
エクスペクテーションを満たすことを明示的に確かめる
診断はファーストクラスのフィーチャ
序論
情報の表現ではなく中身をテストする
的確なアサーション
的確なエクスペクテーション
「モルモット」オブジェクト
序論
永続状態に影響をおよぼすテストを分離せよ
テストのトランザクション境界を明示する
永続操作を行うオブジェクトのテスト
オブジェクトが永続化できることのテスト
だけど、データベースのテストは、おそいっ
序論
機能と同時並行性ポリシーの分離
同期処理のユニットテスト
受動的なオブジェクトのストレステスト
テストのスレッドとバックグラウンドスレッドの同期
ユニットテストレベルでのストレステストの限界
序論
サンプリングかリスニングか
ふたつの実装
逃げ出すテスト
更新の検知漏れ
あるアクションが何も影響をおよぼさないことのテスト
同期処理とアサーションの区別
イベント発生源の切り出し
序論
はじまり
噂は広まる
新たな世代
さらなる強化
序論
テストフィクスチャクラス
モックオブジェクトの生成
エクスペクテーションでテストする
エクスペクテーション
序論
独自のマッチャー型を定義する
マッチャーオブジェクトはステートレスであること
索 引
reduce さん
2016-06-11
キレイで安心。コードの書き方。
Kenji Hiranabe さん
2014-08-14
TDDのテストの見取り図が良かった。ただ、JMock の解説読むのは辛い。感想こちら。 http://qiita.com/kenjihiranabe/items/b951b6d98672167347fd
Luo Yang さん
2018-02-18
ソフトウェアの外側の質と内側の質双方を高めながら、オブジェクト指向ソフトウェアを「育てて」いく方法を丁寧に綴った本です。オブジェクト指向ソフトウェアは育てられるのです。この本は、著者らのスタイルとしてjMockをフル活用して進めていくところが大きな特徴でもありますが、それを「実装の詳細」として頭の中で抽象化しながら読んでもなお、現実世界のソフトウェアのテスト駆動開発について、多くの示唆が得られます。特にIV章がよい。
【法人・教育機関のお客様へ】新年度の大口注文・お見積りなど、お気軽にご相談ください
デザインやコーディングなど、Webデザインに役立つスキルが身につく書籍を揃えました
テキスト生成、画像生成、動画生成など、生成AI活用のスキルが身につく本をご紹介
新社会人の役に立つスキルが身につく本。ビジネスパーソンとしてスタートダッシュを切ろう！
小学校から必修化！人気の『ルビィのぼうけん』ほかプログラミング教育の本はこちら
開発・ビジネス・マーケティング・EC運営・営業支援など、幅広いジャンルの講座を開催
