xUnitのルーツから考えると、サンプルコードを書くことから始めるのがよさそう

挫折しないための自分用メモ

 

 

アジャイル開発とTDDを半年間実践してみた顛末と、これから

0-9, TDDの準備としてのサンプルコードテストのすすめ

 

テスト駆動開発ハンズオン後編

 

xUnitのオリジナルはSUnitで、原作者のケント・ベック氏はインタビューでこう答えている。

『JUnit の歴史とテスティングの未来(Kent Beckインタビュー)』を訳します。:An Agile Way:ITmedia オルタナティブ・ブログ

Kent: ぼくの職業プログラマとしての最初は、Smalltalkだった。Smalltakはテスティングの習慣がある。ちょっとプログラムを変更したら、ちょっと動かしてみる。というインクリメンタルなサイクルを回す。でも、それは自動化されていなかった。以前コンサルタントとして開発プロジェクトに助言を求められたときに、自動テストを書いてみるようにすすめたかったが、やり方がなかった。Smalltak でやっていることの構造を、そのままオブジェクトモデルにそのまま実装したらどうなるか考えた。Workspaceがクラスで、変数がインスタンス変数、テストしたいコード片がメソッド。これは、ナイーブなマッピングだ。そこで、マニュアルでテスティングしている部分、すなわち、プリントアウトして期待される結果と比較することを、「じゃあ、ここはコンピュータにやってもらおう」と考えた。これが、assertionの原型。ここまでが、アーキテクチャの起源だ。いつごろだったかな、うーん、1992かな。これが最初のユニットテストフレームワーク

 

ワークスペースとは、Smalltalk環境におけるターミナル画面(+エディタ)のような物。

 

加えてSmalltalkにはサンプル用のコードをクラスにつける習慣がある

(メソッド分類におけるexamplesカテゴリの存在)

 

Pharo(Smalltalkの実装のひとつ)マニュアルより

PharoByExample-japanese/SUnit/SUnit.tex at master · SquareBracketAssociates/PharoByExample-japanese · GitHub

 

\st コミュニティは、長らくテストを重視してきました。\st のプログラミング環境ではインクリメンタルな開発が容易だからです。
\st の伝統的な開発では、プログラマはメソッドを実装するとすぐにワークスペースでテストします。
メソッドのコメントにテストを書いたり、セットアップが必要なテストはサンプルメソッドとして実装したりする場合もあります。
しかしこれらの方法には問題があります。まずワークスペースにテストを書いた場合(イメージファイルを共有しない限り)他のプログラマから使えません。
コメントやサンプルメソッドにした場合、状況は多少改善されますが
それでも、メソッドの開発に合わせてテストを見直し、さらに自動的に実行させるのは簡単ではありません。