TDD Boot Camp札幌2.1に参加してきました！ 今回で３回目の参加です。
前回まではJavaで参加していましたが、今回は最近やり始めたRubyで参加してみました。
講演内容の（主観的な）メモと、感じたことをまとめます。
演習メモ Ruby on Railsコース
Cucumber + RSpec を使ったTDDの大まかな手順
- ユースケースをCucumberの features/*.feature ファイルに書く。１つのユースケースに１個のfeatureくらいのイメージ。featureの中にscenarioは複数書ける
- rake cucumberでまず実行。すると、ステップ定義がないというエラーとともにサンプルコードが表示されるので、それをコピーしておく
- features/step_definitions/*_steps.rb ファイルに失敗するステップ定義を書く。取りかかるのはエラーになった先頭の一つだけ。さっきコピペしたものを使うと楽。cabybaraさんの便利メソッド使うと「〜画面が表示されている」のような前提条件も楽々書ける
- またrake cucumber実行。ステップ定義が正しく書けたなら、テストNGの状態になる（いわゆるRedの状態）
- RSpecに移行する。失敗するテストを記述する
- rspec specで実行。Redになったことを確認したらプロダクトコードを書く
- rspec specで実行。Greenになったらリファクタリング
- 全部Greenであることを確認したら、Cucumberに戻る
- rake cucumberを実行し、次の行のエラー（またはNG）に取りかかる。以下繰り返し
- 早い話、ユースケースをfeatureとscenarioに落としたら、あとはとにかくrake cucumberしてOKでなかったところを上から順番に書いて行けばいいだけ。手順はCucumberを実行したら教えてくれる
全体を通じた感想
Cucumberを使った Acceptance TDD はすごかった
前回までのBoot Campとは違い、テストケースの書き方や手順を覚えるというよりも、プロジェクトが開始してからどのようにTDDによる開発につながっていくか、というところに重きを置いたBoot Campだったと感じました。
とくに私が入ったRubyチームはCucumberを利用したことによりそれが顕著でした。ユースケースから直接Cucumberに落とし込むことができるので、そこをTDDの起点にすることで、顧客の要求から乖離していってしまうことを防ぐことができます。
一番感動したのは、Cucumberを実行することによって、次に自分が何をすればいいのかCucumberが勝手に知らせてくれるということです。シナリオの中でまだテストや実装が終わっていないところは色がついて表示されます。
しかもそれは確実な要件であり、かつ程よく具体的に書かれた日本語の文章です。それを上から順番に片付けて行くだけです。「次になにするんだっけ」→ rake cucumber → テスト＆実装 → 「次になにするんだっけ」→ rake cucumber → テスト＆実装 ……
超シンプルです。 迷わない。導いてくれる感がすごいです。
でもCucumberを現場に導入できるだろうか？
でもCucumberを現場に導入できるか？ と考えたら、難しいですね。
Cucumberのメリットは、顧客が一緒になってfeatureファイルを作成してくれるときにもっとも効果を発揮するものだと思います。一緒じゃなくても少なくとも継続的に確認してもらえる状況でなければいけませんが、顧客はこれをメリットと感じで取り組んでくれるでしょうか。
受入テストを顧客が実施している場合、「これをちゃんと書いておけば、受入テストが自動化できますよ」と言えばアピールにはなると思います。どちらにしても顧客のやる気にかかってきます。このへんは「どれだけ顧客を巻き込めるか」というアジャイル的な課題に近い気がします。
開発者にとっても、メリットだけあるとは言えないと思います。featureファイルのメンテナンスは何よりも優先してやっていかなければ意味がなくなってしまうし、負担が増えると感じる人もいることでしょう。
Boot Campの時間内では残念ながらこのあたりの答えは出せずに終わりましたので、もう少し勉強を続けて可能性を探りたいと思います。
最後に
毎回多大な時間をかけて準備してくださる @shuji_w6e さん、TAのみなさま、本当にありがとうございます！
そして、TDDBC参加３回目にしてやっとグリーンバンドを手に入れた……。感動です！ これからも、acts as professional でいきます！
(vimをもうちょっと覚えないといけないな・・・）
