読者です 読者をやめる 読者になる 読者になる

HOW TO GO

〜昨日の今日とは一味二味違うBlog〜

TDD(テスト駆動開発)の練習をやってみた

dev diary agile

先日、イベント開催のお手伝いをさせて頂きました。
アジャイルサムライベースキャンプ」
http://www.agilesamuraibasecamp.org/

そこに僕のチームメンバーが何名か参加してくれました。

当日の和田卓人さんの講演

TDDの実践は難しいなぁ... → じゃあ練習しよう

そんなわけでTDD(テスト駆動開発)を学んだわけですが、TDDってその意義は理解できても現場で適用するのは難しいと思うんです。
そもそもテストコードを書くという意識が希薄な職場です。我々のチームではようやくテストコードを書き始めた段階。

いきなりTDDを仕事で、というと僕も含めて「うーん...」って感じでした。
ということでとりあえずTDDの作法に則って練習をしてみることにしました。練習なら失敗してもいい。

TDDの素振り

やり方

  • 終業後に集まって2時間やってみる
  • スキルにバラツキがあるのでペアプロ
  • 題材は僕が準備

題材

  • とりあえずみんな慣れてるJavaで簡単なロジックを作ってみる
  • 「時刻表から次の電車を探す機能」を作る
  • 時刻表、指定時間をインプットし、指定時間の直近の発車時間を返却するメソッド

仕様上のポイント

  • 時間またがり、日付またがりのロジックができているか
  • 普通に境界値、同値分割がテストケースとして考えられているか

途中で仕様を追加してみる

  • 土日用の時刻表と平日用の時刻表があったことが発覚。なんてこった。仕様追加。なるはやで。
  • 2種類の時刻表をインプットとする
  • 時間だけではなく、日付もインプットとし、日付から曜日を自動判別して該当する時刻表から電車を探す

このような簡単なロジックであればTDDっぽく進められました。2時間半くらいで4人(2ペア)とも完了しました。
例外的なケースの考慮が若干不足してましたが、まあTDDの練習が主旨なのでよいでしょう。

やってみて

「TDDをやる」ってことを目的とするよりはTDDの考え方に沿ってテストコードとプロダクションコードを書いていくことで、コードはよい設計で読みやすいコードになっていくのかな、と感じました。
目的はちゃんとしたコードとテストコードを書くこと、ですね。

今回の題材からは「なるべく変更を加えず(テストコードも作ったものを活かしつつ)仕様変更に対応する」ということが出来たのですが、仕様追加/変更の内容によってはテストコードの書き直しがあるかもしれません。その場合はどのような書き方がよいのか。違うノウハウがありそうです。
色んなテストコードを書いてみて色んな対応方法を学ばなければ...。経験するしかないですかね。

そういえば

4月に参加した「CI and Testing Unconference in Tokyo」
http://citcon-jp.doorkeeper.jp/events/3473
その時の僕のレポ/感想

ここでの僕のTryは「TDD Bootcampをチームでやる」だったのでした。
若干忘れてたような気がしなくもないですが、なんとか実現できました。