1. Reducing Test Code
Duplication
 テストの不吉な匂いの最たるものは、
コードの重複
 テストコードの重複は、アサーションの
繰り返しにあらわれる

2. Expected Object
 equalsメソッドで比較
 equalsメソッドをオーバーライドしたく
ない場合は、DTOないしテスト特化サ
ブクラスを用いる
 そうでないなら、カスタムアサーション

3. Custom Asserttions
 自分自身で書く、領域に特化したアサー
ション
 テスト可能！
 二通りの方法がある
 既存のコードから、リファクタリングする。
 存在しないアサーションメソッドを呼ぶこ
とによって、中を埋める

4. Outcome-Describing
Verificaton Method
 結果に対する検証を記述する
 カスタムアサーションとの違いは？
 →SUTに対する相互作用を持つこと
 カスタムアサーションは、等値性を検証
するためのシグネチャを持つ
 検証メソッドは、SUTに渡すための任意
のパラメータを持つ。
 カスタムアサーションとパラメータ化テ
ストの中間

5. Parameterized and Data-
Driven Test
 Parameterized Test
 →テスト自動化フレームワークからは呼ば
れない
 →パラメータが必要だから

6.  Data-Driven-Test
 フレームワークによって直接実行可能
 テストに特化したデータをファイルから読
み込む

7. Avoiding Conditonal Test
Logic
 コードの重複とともににさけるべきなの
は、条件判定のロジック。
 テストされないテストコードが発生する
から
 条件判定のロジックが発生する理由
 アサーションを実行したくない
 実際の結果に、いくつかのシチュエーショ
ンがある
 テストメソッドを、異なる状況で再利用し
たい

8. Eliminating “if”
Statements
 テストが失敗したときに、より意味のあ
るメッセージを出したいときに、どうす
べきか？
 よくあるリアクションは、if文をいれる
こと
 テストを走らせるたびに、同じコードが
実行されない
 Guard Assertion(防護アサーション)を使
う

9. Eliminating Loops
 条件判定のロジックは、ループとしてあ
らわれることもある。
 以下の問題がある
 テストされないテストコードが生まれる
 わかりにくい(Obscure)なテストを招く
 開発者がテストを書かなくなる
→テストユーティリティーメソッドで解決す
る

10. Working Backward,Outside-In
 終わりからはじめる
 関数の結果を返すところから書き始める
 アサーションから書き始めることになる

11. Using test-Driven
Development to Write Test
Utility Methods
 テストユーティティーに対するテスト→
テストユーティリティーテスト
 TDDは、テストユーティリティーメ
ソッドの実装を最小限にするのに役立つ
 防護アサーションや、カスタムアサー
ションが有効なので、一般的なロジック
が入る余地はない

12. Where to Put Reuseable
Verification Logic?
 再利用可能なテストロジックはどこに置
くか？
 もっとも的確なのは、テストケースのク
ラス
 テストケースのスーパークラスにpull-up
することもできる。
 Test Helperに移動することもできる。
 詳しくは12章で