■
http://log.giantech.jp/BDDIntro-ja.html
そういえば、角谷さんに「つもり日記」で
済まされて以来、BDDのことはサッパリ
忘れていました。
で、C++の勉強がてら、"TDD"のPythonの
xUnitのところを読みつつ実装してたり
してました。
結局、C++だとリフレクションがないから
自動化は辛いんじゃないの？というのが
結論なんですけど。CPPのマクロでどうにか
なるレベルには思えないんですけど。
あ、いやいや、そういうグチをこぼす
のにこれを書き始めたわけじゃないです。
"TDD"を読むと、ユニット・テストを
テストのためだけに使ってるんじゃ
ないんですね。
ユニット・テストのテスト以外の用途と
いうのは、ゴールをはっきりさせること。
それは仕様といってもいいわけで、
そういう意味じゃ、BDDには納得できるんです。
ただ、でも、それにBDDという名前をつける
ほどなの？という疑問はありますけど。
"TDD"の中でK.Beck氏がいいたいのは、TDDという
全体的なサイクルでプログラミングを進めていく
ことなんです。試行錯誤を支援するツールの
１つとしてユニット・テストがあるんだという
こと。
逆にいえば、BDDという「振る舞い」とか「仕様」
というものにこだわってしまうと、肝心な
サイクルというものを見落としてしまう危険性が
あるということ。
TDDっていうのは、非常に画期的な手法なんです。
これまでプログラミングの本で「テストを先に
書きなさい」と教えた本はなかったんですから。
"TDD"の中で、K.Beck氏が12才になった娘さんに
プログラミングをはじめて教えるときにTDDを
教えたというエピソードが書かれていますよね。
それ以来、娘さんはテストを先に書かなければ
プログラミングはしちゃいけないものだと
思い込んでいる、なんて冗談めかして書いてます。
これがどれだけ画期的なことか、気づかないと
いけません。
- -
http://www.kt.rim.or.jp/~kbk/zakkicho/zakkicho10.html#D20060405-5
そうなんすよ、自分もビックリしちゃいました。
ぼのぼのはゆうに１０年超えてるでしょうね。
もう２０巻くらいいってるんですかね。
前は単行本も買ってたんですけど。
