「テストを最初に書くことのメリット」？

僕が開発をする場合はインターフェースから書き出すことは最近はまずないです。インターフェースを検討するために実装から書き始めます。ある程度実装をして試行錯誤してみてから、インターフェースを書きます。

何故かと言うと、ラフスケッチがないと、本当のインターフェースが見えてこないからです。

僕がTDDを試してみて思うのは、TDDでは試行錯誤の段階がないために、インターフェースの修正を初期段階で頻繁に繰り返すことになるのでロスが大きいということです。

だから、ラフスケッチにTDDは向いていないんじゃないかなと思っています。検討する度にassertionと実装を変更するのは速度が遅く、ラフスケッチには向かないと思っています。

TDDの感覚は、僕にはどうもいきなり本番書いているような感じがしてどうもしっくりきません。ラフスケッチを書いてからインターフェースを決定してテストとしたほうがよいんじゃないかと思います。

多分、Kent Beckの場合は、机上で考えたインターフェースがいきなりある程度安定するんじゃないかと思います。ただ、僕にはちょっと無理ですね。

インターフェースを検討するときには、TDDで検討するのは効率が悪いので、実装書いて動かしながら検討したほうがよいんじゃないかな、というのが今のところの僕の結論です。

ただ、ラフスケッチの時間は短いので実際のところは余り大きな差はなくて、ラフスケッチを頭の中でやるのか、動かして検討するかだけの差だと思います。

# TDD本のサンプル位であれば、いきなり書いてもある程度上手くいきそうです。ただ、実際には事象はシンプルではないので、机上での検討は機能しないんじゃないかなと思うのです。