単体テストの考え方 / 使い方 を読んで

https://book.mynavi.jp/ec/products/detail/id=134252

を読んで、学んだこと、感想をメモしていく。

単体テストと設計との関係

単体テストを作成しづらいと感じるのであれば、そのテスト対象となるコードは何らかの改善を必要としている可能性が高い。
プロダクション・コードの質の悪さは、通常、異なるコード同士が密結合していること (異なるコード同士が適切に分離できない状態になっていること) が原因であり、その結果、コードを分離して個別にテストすることが難しくなっている。

単体テストをすることでソフトウェア開発プロジェクトの成長を持続可能なものにすることを成し遂げる。

テスト・ケースが多いほど良いという考えは間違い。コードは資産ではなく負債だから。コードは最小限にすべき。

質の悪いテストのプロジェクトは、最終的にはテストがない場合と同じくらいの負担がプロジェクトを継続するのに必要となる。

coverage が高いからといって、テスト・スイートの質が高いとは限らない。

ほとんどのアプリケーションにおいて核となる部分はビジネス・ロジックを含む部分、つまり、ドメイン・モデル になる。そのため、テストに費やした時間が価値としてもっとも効果的に返ってくるのはビジネス・ロジックに対するテストということになる。

優れたテスト・スイートには次の特徴がある:

• テストすることが開発サイクルの中に組み込まれている
• コードベースの特に重要な部分のみがテスト対象となっている
• 最小限の保守コストで最大限の価値を生み出すようになっている

単体テストとして定義されるテストには次に挙げる3つの重要な性質がすべて備えられている。

• 「単体 (unit)」と呼ばれる少量のコードを検証する
• 実行時間が短い
• 隔離された状態で実行される

ロンドン学派が考える隔離

テスト対象となるクラスが他のクラスに依存しているのであれば、その依存をすべてテスト・ダブルに置き換えなくてはならない、という考え。テスト対象の振る舞いは外部の影響から隔離されることになるので、そのクラスのことだけに専念できるようになる。

テスト・ダブルを使うことの利点は、テストが失敗したときに、コードベースのどこかで問題が起こったのかを明確にできること。

もう1つの利点は、オブジェクト・グラフ (同じ問題を解決するために結びついたオブジェクトの集まり) を分離できるようになること。
直接的な依存はテスト・ダブルに置き換わるため、そのあとの依存 (依存の依存) を扱わなくても良くなり、さらに、 循環依存 (circular dependency) も断ち切れるようになれる。

テスト対象システムを依存から隔離することで得られる効果として、1つのテスト・ケースは1つのクラスしか検証しない、という指針をプロジェクト全体に普及させられるため、テスト・スイート全体がシンプルな構造になる。

テスト対象メソッド (Method Under Test: MUT) とは、テストの際に呼び出されるテスト対象システムのメソッドのこと。「テスト対象メソッド」と「テスト対象システム」は同じ意味を表すものとして使われることがあるが、通常、テスト対象メソッドはメソッドのことを指し、テスト対象システムはそのクラス自体のことを指す。

モック とは、特別な種類のテスト・ダブルのことで、テスト対象システムと協力者オブジェクトとのやり取りを検証できるようになっている。

テスト・ダブル とは、テストで使われるすべての種類の偽りの依存のことであり、プロダクトで使われることはない。
モック はこのような偽りの依存の1種でしかない。