俺の読んだ TDD はこんな流れだった気がする。
1. テストを書く -> テスト対象が未実装なのでコンパイルエラー
2. コンパイルが通るだけの最低限の実装を書く -> レッドバーになる
3. テストが通る最も簡単な実装を書く -> グリーンバー
4. いーかげんな実装でテストがパスしてしまうようであれば、テストが不十
分なのでテストを追加する(三角測量とかいう表現)
5. 3と4を何回か繰り返し、十分なテストと、それにパスできる実装が実現で
きたら、リファクタリングを行い、冗長性とかわかりづらい表現を取り除く

リファクタリングフェイズで、あらためてソースを見直すので、原則的には後
で取り除くべきことを記憶しておかねば*ならない*ということはないはず。

実装時にちょっと気を使えば余計なリファクタリングの手間が減るじゃん、と
か思うかもしれないが、後から見直すことによって気がつくことも多いので、
必ず最後にリファクタリングを行うべし、ということだと思う。

テストを書くときと、実装を書くときと、リファクタリングをするときで、仮
想的に人格を使い分けることが求められるので、「あほくさ」と思う人もいる
んだろうな、という気はする。