テスト駆動開発を読んでみたおぼえがき

はじめに

Kent Beck 著、和田卓人 訳な『テスト駆動開発』を読んだ覚書。 タイミングが良いことに、仕事先のお試しプロジェクトをテスト駆動開発で進める機会があったので、これについても感想を綴ります。

テスト駆動開発とは

• Red→Green→Refactor を小さいステップで高速で回す
  • Red … 書いたテストを実行してレッドバーの表示を確認する
  • Green … とりあえずテストが通る形で実装する
  • Refactor … 引数で取得できたり、柔軟に変更できる箇所をリファクタリングする
• ブラックボックステストを仮定して、投入するものと期待する結果を考える
  • やりたいことを明確に表現できる
• 実装ではなくテストから先に考える
  • 開発をシンプルにすすめることができる
• テストを書く理由
  • リファクタリングをするときの精神安定剤
  • テストが通ることで品質を担保(?)

個人的に大事だなと思ったのはこんなところ。

特に、やりたいことを最初にテストで表現する、という部分に惹かれた。 実装の前と後に書かれるテストは中身が変わるのかなと思った。というのも、実装後に書くテストはホワイトボックステストになりがち（だと思う）だが、、実装前にテストを書くことでブラックボックステストになりやすいと思う。 その結果、内部の仕様を変更したとしてもテストがコケにくくなり、テストの保守に労力をあまり割かなくて良くなるのかなと感じた。

あとは Red, Green, Refactor を小さいステップで回すことで目標に向かって柔軟に実装できるという箇所が読んでて「素晴らしい…」ってなるポイントだった。

テスト駆動を実施してみて

ここまでは本で読んで「こういうことかな〜」という話。 ここから先は 1 ヶ月に満たない短い期間でテスト駆動開発を実際に導入してみてのオハナシになります。

実際に導入してみるとなかなか理想通りにはできなかった。 うまくいかなかった事例としては以下の通り。

• テストで担保するべき最低ラインで意見が割れる
  • そもそも個々人でテスト力がバラバラなので当然
• Red, Green, Refactor の Red は意識しないとすっ飛ばす
• 「あれ、これはスモールステップではない…?」
• テスト駆動のハズが、「こんな感じでは？」と話しているうちに実装が終わってしまう
• テストがホワイトボックステストっぽくなる

そもそも本読んだだけで、1 ヶ月の間で初テスト駆動開発というのは無理があった。 とは言うものの、やってみるとテストのありがたみの片鱗を知ることができたのでいい経験になりました。