リファクタリングとTDD

リファクタリングは、あまりリファクタリングのことを知らない他人もしくは過去の自分が書いたコードが健全になるように修正するもので、今自分が書いてるコードのためのものじゃないと個人的には思います。
自分でコードを書いているんだったら、最初からリファクタリング不要なコードを書けばいいからです。人は、コードを書いたそばから忘れていくものですから、コードを書いているときが一番コードについて分かっているはずです。後から思いつくことも当然あると思いますが、そのようなケースはそれほど無いんじゃないでしょうか。
もし、後から思いつくことが多いとしたら、最初にコードの意味を理解して書いていないためではないでしょうか。
テストを書けば、書いたコードの意味を確かめることができます。コードの意味を理解していれば、最初からリファクタリング不要なコードを書けるのではないかと思います。
私が後からコードを変えることがあるのは、最初に書いたコードを汎用的にするときです。最初はその目的を達成するために最もシンプルなコードを書きますが、後から似たような処理が出てきて、もとのコードを汎用的に利用できるようにする場合です。
そのときは、publicなメソッドも変えることがあるので、リファクタリングとはいわないと思っています。
Seasarの話でいうと、framework.container直下のインターフェースのようなpublishedなものは、慎重に吟味してメソッドを変更をするようなことは基本的にしません(メソッドの追加はありますが)。YAGNIといってもフレームワークのインターフェースを変えることはユーザに対するインパクトがでかいためです。
それに対し、containerの配下にある実装パッケージ(implなど)は、機能を追加するときにpublicなメソッドも変更する場合があります。
まとめ

最初からリファクタリングを前提に設計するっておかしくないかなぁ。

追記

最初からリファクタリングを前提にするというより、常にある時点で最もシンプルな実装をするということでいいのではないかと思います。publishedなインターフェースは後から帰ると影響が大きいので、それについては最初から慎重に設計することが必要。