TDD.NET

( きちんと隠蔽された ) オブジェクトは、 内部的な構造はもちろん、 その状態を外部から見ることはできません。 状態が露出されないため、 内部的な構造や状態を照会し、 その状態をアサートの条件にすることによって、 オブジェクトの振る舞いをテストすることは不可能で す。 外部から見えるのは、 オブジェクトが周囲の環境と対話している "ようす" だけです。 しかし、 これらの対話を追跡することによって、 オブジェクトの振る舞いを確認することができます。

ユニットテストの基本は、 メソッド単体の振る舞いを定義し検証することです。 しかし、 プログラムを設計するという観点からは、 そのひとつ上のレベルである、 オブジェクトの振る舞いを定義し検証することが必要になります。 メソッドの中身を見ないようにしてメソッドの振る舞いを定義するユニットテストを書くように、 オブジェクトの振る舞いを定義するユニットテストもそのオブジェクトの内部状態に依存すべきではないでしょう。 メソッドもオブジェクトも、 テストのカタチで先に振る舞いを定義 ( 外部設計 ) せよ、 というわけですね。
※ 振る舞いを重視し先に決めるようにして開発を進めていくのだから、 TDD ではなく BDD ( Behavior-Driven Development ) と呼ぼう、 という動きが数年前にありました。 あまり定着しなかったように思います。

モック オブジェクトを使用すると、 特定の状況において、 オブジェクトから適切なメッセージがコラボレータに送信されている、 ということをアサート (表明) することにより、 オブジェクトがそのコラボレータとどのように対話しているかを見極めることができます。 そのため、 オブジェクトをどのように分類し、 どのような構造にするか、 という視点ではなく、 むしろ、 オブジェクトが互いにどのようにやり取りするかが設計の中心になります。

ここでコラボレータ ( collaborator : 共に働くもの ) とは、 着目しているオブジェクトと協調して動作するもの、 つまり、 着目しているオブジェクトから呼び出される ( あるいは、 呼び出す ) オブジェクトです。
コラボレータがまだ実装されていない ( これから設計する ) 段階で、 コラボレータのかわりに柔軟なモックオブジェクトを使うことで、 着目しているオブジェクトの実装とコラボレータの振る舞いの設計を同時に進めることができます。 この記事では、 その手法を、 POS システムを設計するというサンプルで説明しています。