「オブジェクト指向設計実践ガイド」 第9章 費用対効果の高いテストを設計する

第9章 費用対効果の高いテストを設計する

変更可能なコードを書くのに必要な3つのスキル

1. オブジェクト指向設計の理解
2. リファクタリングのスキル
3. テスト設計のスキル

※リファクタリングとはコードの機能を変更せずに内部構造を変えること

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

テストの意図

テストを行う目的は、コストの削減である。テストに伴って、次のような利益が得られる。

• バグ発見 早期にバグを発見できる
• テストが仕様書代わりとなる 紙の仕様書をメンテナンスし続ける必要がない
• 設計の決定を遅らせる テストがあることにより安心してリファクタリングできる
• 抽象を支える 全体の振る舞いを記述できる
• 設計の欠陥の発見 テストが書きづらいコードはコンテキストを要求しすぎている

より少ないテスト

テストはなるべく少ない方が良い。テストの数を安全に減らすためには、テストを何のために書くのか考える必要がある。

まず、オブジェクト指向におけるテストとは、オブジェクトが他のオブジェクトからメッセージを受け取った際に「期待される動作」をするかどうかのテストである。ということは、パブリックインターフェースに関するテストのみ書くべきである。(プライベートなメソッドに対するテストは不要！)

テストすべきなのは

• 受信メッセージ(オブジェクトがメッセージを受取ったら期待するメッセージを返すこと)
• 送信コマンドメッセージ(副作用を持つメッセージは送られた回数、使われた引数を検証する必要がある)

のみである。

受信メッセージのテスト

• 使われていないインターフェースは削除する
• パブリックインターフェースの仕様を保証する
• 依存するオブジェクトはテストダブル・スタブを活用し、テスト対象ではないオブジェクトの影響をなくす (これを実現するには依存性の注入ができていないと！)

プライベートメソッドのテスト

• 基本的にはプライベートメソッドをテストする必要はない
• リファクタリング予定があるときは書いておくとリファクタリングを進めやすくなる。

送信メッセージのテスト

• 副作用のある送信メッセージが正しく送られるか、モックに対してメッセージを送らせてテストする

ダックタイプのテスト

• 暗黙的に存在するタイプはテスト内で明示する

継承のテスト

• リスコフの置換原則が守られているかテストする
• 抽象クラスのテストにはテストスタブ用のサブクラスを活用する

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方