普段からTDDでコーディングされている方にとっては当然のことだと思いますが，自分への確認と戒めの意味でまとめてみました．
TDDでコードを書き出す理由は2つだけです．
1: リファクタリングのため
「グリーン」だけど「スパゲッティな」コードを改善する場合です．
できるだけ綺麗なコードを目指しましょう．
2: レッドを抜け出すため
レッドからグリーンを目指してコードを書き改める(or 書き出す)場合です．
2-a: 新規コードを書き出す
新たにコードを書き始めるときはこれに当てはまります．
実現したい機能をテストで表してコーディングに取り掛かります．
典型的な Test first !
2-b: バクの修正
バグの修正もこれに当てはまります．
バグが原因でコケるテストを作り，グリーンを目指します．
面倒に感じるときもありますが，オススメのやり方です．
バグの歴史をテストで記録しておくことで，それ以降の精神衛生が保たれます．
雑談その1: ルールは大事だけど
ごちゃごちゃ書きましたが，要は Test first です．
ただ，このルールを完全に守ろうとするのは最善だとは思いません．
TDD原理主義は逆効果なので，もっと柔軟にプログラミングしましょう．
例えば，Java であれば hashCode/equals/toString/getter/setter をいちいちテストする必要はあまり感じません．
雑談その2: TDD = プログラマの精神安定剤
もし，TDD がなかったら(もっと多くの)プログラマの心が折れると思います．
リファクタリングの度に，バグの不安に駆られるなんてイヤです(よね?)．
そういう意味で，TDDはプログラマの精神安定剤です．
元気なときには飲むのが面倒なのも薬と似ています．
プロジェクトが健康なうちに TDD という薬を飲んでおけば，技術的にも精神的にも happy な生活ができるはずです．
