Reducing Test Code Duplication

テストの不吉な匂いの最たるものは、コードの重複

テストコードの重複は、アサーションの繰り返しにあらわれる

Expected Object

equalsメソッドで比較

equalsメソッドをオーバーライドしたくない場合は、DTOないしテスト特化サブクラスを用いる

そうでないなら、カスタムアサーション

Custom Asserttions

自分自身で書く、領域に特化したアサーション

テスト可能！

二通りの方法がある

既存のコードから、リファクタリングする。

存在しないアサーションメソッドを呼ぶことによって、中を埋める

Outcome-Describing Verificaton Method 結果に対する検証を記述する

カスタムアサーションとの違いは？

→SUTに対する相互作用を持つこと

カスタムアサーションは、等値性を検証するためのシグネチャを持つ

検証メソッドは、SUTに渡すための任意のパラメータを持つ。

カスタムアサーションとパラメータ化テストの中間

Parameterized and Data-Driven Test Parameterized Test

→テスト自動化フレームワークからは呼ばれない

→パラメータが必要だから

Data-Driven-Test

フレームワークによって直接実行可能

テストに特化したデータをファイルから読み込む

Avoiding Conditonal Test Logic コードの重複とともににさけるべきなの

は、条件判定のロジック。

テストされないテストコードが発生するから

条件判定のロジックが発生する理由 アサーションを実行したくない

実際の結果に、いくつかのシチュエーションがある

テストメソッドを、異なる状況で再利用したい

Eliminating “if” Statements

テストが失敗したときに、より意味のあるメッセージを出したいときに、どうすべきか？

よくあるリアクションは、if文をいれること

テストを走らせるたびに、同じコードが実行されない

Guard Assertion(防護アサーション)を使う

Eliminating Loops

条件判定のロジックは、ループとしてあらわれることもある。

以下の問題がある

テストされないテストコードが生まれる

わかりにくい(Obscure)なテストを招く

開発者がテストを書かなくなる

→テストユーティリティーメソッドで解決する

Working Backward,Outside-In

終わりからはじめる

関数の結果を返すところから書き始める

アサーションから書き始めることになる

Using test-Driven Development to Write Test Utility Methods テストユーティティーに対するテスト→

テストユーティリティーテスト

TDDは、テストユーティリティーメソッドの実装を最小限にするのに役立つ

防護アサーションや、カスタムアサーションが有効なので、一般的なロジックが入る余地はない

Where to Put ReuseableVerification Logic?

再利用可能なテストロジックはどこに置くか？

もっとも的確なのは、テストケースのクラス

テストケースのスーパークラスにpull-up

することもできる。

Test Helperに移動することもできる。

詳しくは12章で