xUnitのルーツから考えると、サンプルコードを書くことから始めるのがよさそう
挫折しないための自分用メモ
xUnitのオリジナルはSUnitで、原作者のケント・ベック氏はインタビューでこう答えている。
『JUnit の歴史とテスティングの未来(Kent Beckインタビュー)』を訳します。：An Agile Way：ITmedia オルタナティブ・ブログ
Kent: ぼくの職業プログラマとしての最初は、Smalltalkだった。Smalltakはテスティングの習慣がある。ちょっとプログラムを変更したら、ちょっと動かしてみる。というインクリメンタルなサイクルを回す。でも、それは自動化されていなかった。以前コンサルタントとして開発プロジェクトに助言を求められたときに、自動テストを書いてみるようにすすめたかったが、やり方がなかった。Smalltak でやっていることの構造を、そのままオブジェクトモデルにそのまま実装したらどうなるか考えた。Workspaceがクラスで、変数がインスタンス変数、テストしたいコード片がメソッド。これは、ナイーブなマッピングだ。そこで、マニュアルでテスティングしている部分、すなわち、プリントアウトして期待される結果と比較することを、「じゃあ、ここはコンピュータにやってもらおう」と考えた。これが、assertionの原型。ここまでが、アーキテクチャの起源だ。いつごろだったかな、うーん、1992かな。これが最初のユニットテストのフレームワーク。
ワークスペースとは、Smalltalk環境におけるターミナル画面（+エディタ）のような物。
加えてSmalltalkにはサンプル用のコードをクラスにつける習慣がある
（メソッド分類におけるexamplesカテゴリの存在）
Pharo(Smalltalkの実装のひとつ)マニュアルより
\st コミュニティは、長らくテストを重視してきました。\st のプログラミング環境ではインクリメンタルな開発が容易だからです。メソッドのコメントにテストを書いたり、セットアップが必要なテストはサンプルメソッドとして実装したりする場合もあります。コメントやサンプルメソッドにした場合、状況は多少改善されますがそれでも、メソッドの開発に合わせてテストを見直し、さらに自動的に実行させるのは簡単ではありません。