TDDワイワイ会でテスト駆動開発に再挑戦しました

tddyyx.connpass.com

最近会社のチームでTDDをやり始めたばかりなのですが、チームの先輩に誘われてTDDをやってみるイベントに参加してみました。TDD本は読んだことがあるのですが、あまり腹落ちしきっておらず、もう一度読まないといけないかなと思っていたタイミングだったので、実践で理解を深める良い機会でした。

進め方

4人1チームに分かれて、cyber-dojoのお題をやっていくというオーソドックスなスタイルなのですが、一番良かったのはワイワイ会の運営スタッフの方にファシリテーションを行っていただけたことです。TDDの進め方のスライドがあらかじめ準備されており、導入部分が型として磨かれていたので、スムーズにTDDに入ることができました。

今回のTDDはモブプロ形式を取り入れ、REDの状態からDriverが作業を開始し、最低限の実装でGREENにする->コードをリファクタリング->新しいTodoのテストを書いてREDになったら交代、というサイクルでした。以前会社のチームで一回モブプロをしたときは、上の3ステップの1つが終わるごとにDriverを交代していたのですが、上記1サイクルを1人でやる方がTDDの勘所をつかみやすくて良いかもしれません。

↑テスト結果がREDでもGREENでも、予想通りであればみんなで場をワイワイ盛り上げます。ここ大事。

Todoを整理する

今回最も学びになったのは、コーディングに入る前のTodoを処理ではなく振る舞いをもとに考えることでした。コードを書く立場としてどうしても実装単位で考えがちですが、振る舞いから考える方が仕様を網羅するという意識を持ちやすいうえ、テストケース分解・責務分解につながりやすくなります。

TDDとスクラム

今回はTDDを体験した後、他の参加者の方と「TDDをスクラム内でどう活かすか」という議論になりました。
個人的には、Todo整理にはスクラムでのプランニングに通じるところがある感じを受けました。弊社のチームの場合、実装に移る前のプランニングスプリントで要求を要件に落とし込み、PBIを作ってから細かな実装タスクに落とし込むというやり方を取っているのですが、テストを書くことはそこで決めたPBIを表現し担保するという意味合いを持っているのかもしれません。
とはいえ、スクラムの中核にTDDを置くこともまた正しくはなさそうです。DB設計など、変化することが少なくなおかつアプリケーション全体に大きな影響を及ぼすようなものは、TDDで高速改善していくスタイルには合わないでしょう。むしろ、PBIに紐づく実装タスクの方がTDDの威力を発揮できそうです。これからTDDを取り入れる場合、小さな実装タスクから始める方が失敗しにくいかもしれません。

※ちなみに今日は「誰も全く知らない言語でいきなりFizzBuzz TDDをやってみる」という猛者チームをいくつか見かけました。ドキュメントを見て書き方を議論しながら実装するというハードモードなやり方なので人を選びそうですが、ついていければ言語学習のステップを一気に駆け抜けることができる気もします。たぶん。