TDDをやってみたら製造時の不安が大きかったが、それはTDDが原因ではなかった

TDDをやってみたら製造時の不安が非常に大きかったが、途中でやりかたを変えてそれは解消できた。
不安が大きかった理由は、詳細→概要という順に作っていたのでTDDでテストされたクラスを組み合わせたときに本当に目的とする動作が実現できるかの保証が無かったため。またテストコードを書くときに、製造対象の機能とインターフェースを両方考えるせいでチャンクが足りなくなっていた。
動くと確信できる設計ができてないのに詳細→概要という順で製造していことが元凶なので、概要擬似コードで概要→詳細を書いてから、実動作するクラスのコーディングに入るより前にユニットテストを挟み込む感じに手順を変更することで解消した。
うまくいったのは以下のような手順。

クラス設計
 機能概要
 メソッドの暫定リストアップ
概要→詳細で、実装したら動くと確信できる疑似コードを書く
テストを書く
 擬似コードのクラス単位に、RSpecを書く
 テストコードを書く
 テストをコンパイル通るようにする=クラス枠の用意
 実装
 テストGreenにする
実動作テスト

あとTDDはグリーンという餌が目の前に吊るされることによって近視眼的になるのも、ちょっとデメリットかと感じた。
また「テストコードを変更するのが面倒だからインターフェースを変えたくない」という本末転倒な心理も発生する。それを軽減するために強力なリファクタリング支援機能が入ったIDEが必要だと感じる。



http://www.atmarkit.co.jp/ait/articles/1403/05/news035_2.html
上の流れには「アウトサイドインTDD」「モック派」という名前が付いているらしい。
対して詳細モジュールから概要モジュールの順に製造するTDDを「インサイドアウトTDD」「古典派」と呼ぶ。
さらに、RSpec的な振る舞いを重視したテストをするのは「BDD 振る舞い駆動開発」と呼ぶ。

「テストコードをリファクタリングして変更しやすい状態に保つ」というは難しい要求だと思う。なぜならば、「変更しやすい」というのは「どの方向からの変更に対して」というのとセットになった概念であり、どの方向からの変更が発生するかわかっていれば、それはもうクラス設計の方に取り込まれているはずだからだ。
例えばよくstrategyパターンの例にある図形描画のコードの場合、図形の種類を追加するという方向へは変更しやすいが、図形を一気に2つ渡すようにしたいという方向へは変更しづらい