テスト駆動開発にうまくなじむ方法

InfoQ: テスト駆動開発導入時のよくある質問

というエントリが日頃考えていることと内容がマッチしていたので興味深く読んだ。
そこからたどって以下のエントリも読んでみた。

• The first 2 hours of TDD are the most painful – Chad Myers’ Blog
• ThoughtStream.Create(me); : In response to Chad Myers’ TDD questions

「TDDに関する本やブログを読みあさったけど意味がなかった」「そばによいペアがいればそんなことないんだけど」などといったコメントが印象的。
やっぱり経験者とのペアプロが一番いいんだろうなぁ。百聞は一見にしかずということで。

自分もたまに「テストってどう書いたらいいんでしょう？」みたいな質問をされるのだけど、明確なアドバイスを返せないでいたのでこれを期に考えてみた。

まず経験者が周りにいるならペアプロするか、プログラミングしているところを見せてもらうのが一番いい。

経験者が身近に誰もいない環境で始めるのならば、意味があるのかとか役に立つのかとか考えずテストを書き続けるのがいい。
たぶんテスト駆動開発にチャレンジしてみたけどなじめずやめてしまう人というのは、ちょっと試して効果を実感できないうちに疑問を感じてやめてしまうケースが多いと思われるので。

また何に関してテストを書いたらいいのかわからんと思うけど、とりあえずテストのシンタックスに慣れる意味も兼ねて、シンプルにすべてのメソッドに対してひとつずつテストを書く。
愚直に数ヶ月書き続けることで自然とわかってくることがあるだろう。

わかるまで手を動かすという方法は効率は悪く感じられるかもしれないけど確実ではある。それに実は思ったほど無駄でもないはず。
繰り返しになるけど効率を求めるなら経験者を捕まえていっしょにキーボードの前に座るのがベスト。

座学より実技で。