担当割当表/Part4
Part IV: 持続可能なTDD(Sustainable Test-Driven Development)
ここでは、開発が「快適である」状態を維持するためにはテストコードの質をどのようにすべきかを議論する。 テストコードにだって、プロダクトコードと同じくらいの気配りが必要だ。 テストがしづらければテストコードを修正する必要があるが、それはたいていの場合、そもそもプロダクトコードの設計がまずいのでは?というヒントでもある。
ここではガイドラインを分割された章にまとめたが、本書に収めるためになるべくまっすぐな構成にするにはまだまだやるべきことが残されている。 具体的な例として、各章で述べている 質 は相互に関連し、補いあっていることが挙げられる。 テスト駆動開発とは、テスティング、仕様化、設計といった別々の行為を、1 つの全体的な行為に包含するものなのだ。
Chapter 20: テストの声を聴く(Listening to the Tests)
見出し | 担当 | 完了 |
---|---|---|
はじめに | yujiorama | 2012/08/19 |
モックで置き換えたいけど、裏技なしでは不可能だ | yujiorama | 2012/08/19 |
ログ出力もフィーチャ | yujiorama | 2012/08/19 |
具象クラスのモック | yujiorama | 2012/08/19 |
値はモックしない | yujiorama | 2012/08/19 |
ばかでかいコンストラクタ | yujiorama | 2012/08/19 |
よくわからないオブジェクト | yujiorama | 2012/08/19 |
依存関係が多すぎる | yujiorama | 2012/08/19 |
エクスペクテーションが多すぎる | yujiorama | 2012/08/19 |
テストが教えてくれること(ただしテストの声を聴いたときに限る) | yujiorama | 2012/08/19 |
Chapter 21: リーダブルテスト(Test Readability)
見出し | 担当 | 完了 |
---|---|---|
はじめに | tomy_kaira | 2012/08/19 |
フィーチャを表すテスト名 | tomy_kaira | 2012/08/19 |
標準的なテストの構造 | tomy_kaira | 2012/08/19 |
テストコードの合理化 | tomy_kaira | 2012/08/19 |
アサーションとエクスペクテーション | setoazusa | 2012/08/19 |
リテラルと変数 | setoazusa | 2012/08/19 |
Chapter 22: 複雑なテストデータの扱い(Constructing Complex Test Data)
見出し | 担当 | 完了 |
---|---|---|
はじめに | 9/23 | |
テストデータのビルダー | 9/23 | |
よく似たオブジェクトの作成 | 9/23 | |
ビルダーの合体 | 9/23 | |
ファクトリーメソッドを使ってドメインモデルを強調する | 9/23 | |
重複の削除の実例 | 9/23 | |
コミュニケーションが第一 | 9/23 |
Chapter 23: テスト診断室(Test Diagnostics)
見出し | 担当 | 完了 |
---|---|---|
失敗させるための設計 | 9/23 | |
小さくて狙いが絞られており、うまい名前がついているテスト | 9/23 | |
説明的なアサーションメッセージ | 9/23 | |
マッチャーで詳細を際立たせる | 9/23 | |
自己言及する値 | 9/23 | |
仕込まれたことが明らかな値 | 9/23 | |
トレーサーオブジェクト | 9/23 | |
エクスペクテーションを満たすことを明示的に確かめる | 9/23 | |
診断はファーストクラスのフィーチャ | 9/23 |
*1 この相互関係性は、題材を密接な関係を持つ章に分割していくことをとても困難にしたものだ。
Keyword(s):
References:[FrontPage]