Agile Samurai Base Camp 2014 Re:TDDに参加してきました
ブログ書くまでが勉強会ですよ。ということで。
細かいところは http://togetter.com/li/657283 にまとめてくださってるそちらを見ていただければと思います。講演資料とかもリンクがついてます
質問コーナー(お悩み相談室になってた)で直接 @t_wada さんに質問する機会があったので、「TDDはテストを書いてなぜRedから始める必要があるのか?最初にコード書いてからテスト書いてもいいのでは?」という質問をしました。自分の中ではハードルの1つだったんですよ。
回答は次のとおりでした。
テストコード自体が間違っている可能性がある。最初に小さいテストコードと仮実装して細かく作って回したほうが、テストコード自体の間違いに気づくため。
ただし「最初に書く」というのは非常に難しい。大切なのはテストコードがある状態なので後に書いても大丈夫。最初のうちはテストケースを後で書いて、慣れてきたらテストファーストで書く
あとは懇親会とかで話をしてた時に出てきた話としては
- TDDに巻き込むためには最初のサンプルが大切。トップダウンでTDDにしよういっても、どうテストを書いていいのかわからないことが多い。
- リファクタリングタスクを作らない。タスクにすると、工数を確保するための説明責任が発生するのでリファクタリングも実装フェーズに入れる
- TDDを導入するときは無理しない。自分が折れるから。(ここは質問や懇親会でも話が出てきて折れる人が多いんだなぁと実感)
- 実際のコード行とテストコードの行数が1:1ぐらいになるように作ってみる.(実際は1:3ぐらいになるかも)テストコード量が1:10とかの比率になる時はテストコード内部で重複コードがあるので見なおしてみる
- ただし、1:10になるというのが悪いとは思わないとおっしゃってた方もいるので、一概には言えないのかもしれない
- テストもプログラムの一部なのでそこを意識してメンテしていく(テストコード自体のリファクタリングとか)
- 複雑なものはコントローラーのEnd-To-Endでテストする
- うちの会社は横のつながりが弱いのでなにか共有する方法作ったほうがいい
他に気になったのはJUnit+GroovyとSpockの組み合わせ。調べる時間が必要だけど、だいぶシンプルにテストコードが書けそうな気がしています。次の開発のあまり難しくないところで試してみたい
TDDのスペシャリストである@t_wadaさんと直接お話しできたのは非常に嬉しかったし、事例を聞けたのは非常にためになりました。何か実践してBootcampに資産を持って無事に帰ってくる事ができれば幸いです。