>>72
>各クラスの使用をしっかり決めて、危険そうな箇所だけテストケース書くとかじゃだめなのかな？

主観だと断っておくとして、
テスト駆動開発は、テスタビリティと保守性に優れた設計および実装と、
結果として得られる自動テストスイートを、
低コストで安定して得るための方法論であり、
その結果得られる安心と勇気こそが、TDDの価値であると思っている。

そのためのアレンジは認められてしかるべきだと思うし、
逆に、テスト駆動開発の原則に縛られて生産性を損なうようでは本末転倒。
「こんなの自明で、より最適な設計や実装もなければ、バグが入り込む余地もない」と
開発者が皆思うようなところは、TDDはしない。
つまり、1+1=2をTDDしない、ということ。

ただし、注意しなければならないのは、「その設計と実装の正当性はホントに自明か？」ということ。
あなたが当たり前のように実装したコードに、実はバグが潜んでいるかもしれない。
または、今月のあなたが最適と思って設計し実装したコードが、来月のあなたにとってはクソのように思えるかもしれない。

そういう判断は難しい。あなたのいう「危険でない」は、どの程度信用できるのか？
安心して信用できるまでは、TDDのルールを破るべきではない。

ただし、比較的判断しやすいところとして、
>>70で挙げたような自動生成されたコードがある。これはTDDしなくていいだろう。
getter/setterだけでなく、コンストラクタを自動生成できるツールもあるので
それらの機能の利用を薦める。IDEならEclipseとか。
つうか、DTOをネタにするのは、この辺で止めた方がいいね。

まとめると、TDDは安心と勇気を手に入れるための手段なので、
安心と勇気が損なわれない程度にはアレンジしてよし。
ただし勇気と蛮勇の違いに注意せよ。