弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた．
個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく．
僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う．
紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数を受け取って，こういうときにはこういうものを返す，こういうとき例外を投げます，みたいなのをひと通り書いていく．それで書いてると辻褄が合わなくなったりする．こういう変なときは誰がどこで止めてくれるのか，例外が出るのか，メッセージが出るのか，その間にこうなったときは，とか，考えることはいろいろある．
そこまで考えたら文章にまとめてチームメンバーに見てもらってもいい．そこで他人が見たら変なことが分かったり，いいじゃんってなるとか，一人で見るのと，二人で見るのは全然違う．
図とか，文章の上でじっくり考えて，うまくいきそうになってから，ようやくテストを書いたり，実装を始めたりするのがよいと思う．
一方で，オブジェクト指向入門という本を読むと，UMLとか，モデリングツールなどは要らなくて，地続きにコンパイラの支援を受けながらクラスの契約の設計から実装までなめらかに記述していくことができると述べられていてかっこいい．Perlにはそういうパラダイムはないので，早くそういう時代になってほしい．