これ僕.com:行動分析学マニアがおくる行動戦略

意図と行動のギャップから生じる「不自由さ」への挑戦。果たして僕たちに自由はあるのか?

曳光弾開発とテスト駆動開発

Ship it!の曳光弾開発(TBD:Tracer Bullet Development)とテスト駆動開発(TDD)って
どう絡めるのかな〜と、ぼんやり考えてみる。


TBDって、システムを動かすことができる状態を保ちながら、
ダミー処理を実処理に徐々に置き換えていくわけですが、
このダミー処理ってTDDの"Fake it"の状態でわないかと。
そこを接点するといいのでわないかと。


こんな感じ。
1. 受け入れテストを記述
2. Fake it(TBDの第1歩。この時点で固定データだけど画面遷移できるようにする)
3. 三角測量でテストを赤くしておく(TBDでいうところの"to be done:未完成"を明示)
4. システムオブジェクトの定義
5. システムオブジェクト間のインタフェース(やり取りするデータとメソッドシグネチャ)を定義
6. インタフェースに対して機能テストを記述
7. 機能テストに対してFake it
8. 三角測量で赤くしておく
以後、通常のTDDで作業していく。


5〜8辺りがどうかなぁ。
最初にインタフェースを固めるのは難しいだろうから、
テスト書いちゃうと変更したときに大変そう。
それでもテスト書くのがいいのか、
書くか書かないか判断しながら進めるのがいいのか。
ま、取り敢えず書くんだろうな。