TDDBC横浜#3 参加レポート

tddbc event report

TDDBC横浜#3 に参加してきました

2013/10/05（土）に行われた、 TDD Boot Camp 横浜 3rd に参加してきました。

前々から TDDBC には興味があったのですが、今回初参加させていただきました。

結論から言うと、非常に楽しく、また収穫の多い勉強会でした。

参加した背景

私自身は、ユニットテストを書くことが当たり前とされている環境で働いていて、またテストコードの必要性も自分なりには理解している立場です。

しかし Test Driven できているか、というとそうでもなく、実際に TDD を実践している方々のお話を聞いてみたいと思い、また業務以外でのペアプロ経験がなかったのでそれも体験してみたいと思い参加しました。

基調講演

最初は @yattom さんの基調講演 （資料はこちら）でした。

要点を箇条書きにします。

  • TDD の真の目的は健康

  • TDD におけるテストとは、デベロッパーテスト

    • プログラマの、プログラマによる、プログラマのための、プログラムとしてテストを書きながら、開発を行っていく手法
  • リファクタリングによって、常にきれいを保つ
    • 黄金の回転の主軸
    • もちろんテストコードもリファクタリングする
  • TDD のこころ
    • ひとつずつ、少しずつ
    • 自分が（テストする）プロダクションコードの一番最初のユーザ
    • 不安をテストにする （祈るのではだめ！）
    • TDD はスキルである
      • TDD は練習して上達する
  • 困ったときに読む本の紹介

どれもその通りと思う内容でした。

個人的に感銘を受けたのは Uncle Bob (Clean Code の著者で、 TDD三原則 を提唱した人物; 本名は Robert C.Martin）が発案したグリーンバンドの目的です。

  • Uncle Bob 自身でも、テストコードを省きたいと思うことがある。そのとき、左手に嵌めた「acts_as_professional」と刻まれたグリーンバンドを見る。「プロとしてテストは書かないといけない」と自分を戒めてテストコードを書く。

テストコードを省きたい、自分もそんな心境になることは多々あります。 だいたい、そういうときは自分に都合の良い言い訳を考えるものです。 テストを書く時間がない、動かしてみて動いたら大丈夫でしょ、どうせ使い捨て、etc*1。

でもそれは、言ってしまえば「プロの自覚が足りない」ということになるでしょう。プロとして、テストは書かないといけない、テストの無いレガシーコードは書いてはいけない。これからは、もっと強く意識しなければいけないと気づかされました。

TDD デモ

午前中の第二部は、 FizzBuzz をお題にした TDD とペアプロのデモでした。

最初に TODO リストを作り、ペアプロで実際に TDD で開発していくというデモです。TODO リストをそのままテストケースに起こし、実行してレッドになったら実装してグリーンにする、という流れです。

興味深かったのは、実装レベルで TODO リストを作るという点と、テストケースを作りレッドになった時点で交代、を基本に進めていた点でした。

自分自身、タスク駆動やチケット駆動は実務でも行っているのですが、

  • 1が入力の場合は1を返す
  • 2が入力の場合は2を返す
  • 3が入力の場合はFizzを返す
  • 0以下、101以上はあとまわし

というようなテストケースレベルで TODO を起こしたことは無かったので*2 新鮮でした。

2013/10/07（月）19:30 追記

Twitter で補足リプライをいただきましたので、追記します。

これは納得しました。少し複雑目の業務ロジックで同じようにやったら、 TODO リストがすごい長くなってしまうような気がします。

それでも、ある程度の抽象度を維持しつつも、細かく TODO リストを作っていく、のがテストケースを作る上では重要なんだろうなあと感じます。 また、TODOリストが長くなるなら、そもそもメソッドの責務が大きすぎる、ということに気づける良いきっかけなのかなとも思うところです。

私の場合、どちらかというと、テストを先に書くのではなく、 少し実装を書いて、仮に組み上がったらテストを作りグリーンにして、実装を追加していく、という流れで実装していることが多かったです。

TODO リストを作れば、それがそのままテストケースにできるのですから、なるほど、TDD とはより相性が良いのだなと気づかされた次第です。

テストがレッドになったら交代、というのも、TDDでペアプロするなら確かに有効な方法の一つだと気づかされたところです*3。

TDD 実践（ペアプロ）

午後は、いよいよお楽しみのペアプロによる TDD の実践です。

お題は Java の奇妙なバージョン で*4、以下の3イテレーションスケジュールが設定されました*5。

  • 13:00 - 13:50 実装セクション1
  • 13:50 - 14:20 レビューセクション1
  • 14:20 - 14:30 休憩1
  • 14:30 - 15:20 実装セクション2
  • 15:20 - 15:50 レビューセクション2
  • 15:50 - 16:00 休憩2
  • 16:00 - 16:50 実装セクション3
  • 16:50 - 17:20 レビューセクション3

言語は Java, Groovy, Ruby, PHP, JavaScript, C++ のいずれかで挑むことになっていて、私は PHP での参加となりました*6。

知らない人とペアプロをする、というのは私自身初めての体験でしたが、ペアとなった @konkon1234（参加レポート） さんの人柄にも助けられ、かなり楽しく、それなりにスムーズにペア作業をさせていただくことができました*7。

途中のレビューセクションでは、問題掲載用紙に掲示されていた疑似言語によるサンプル*8に似せた作りにした実装に対するマサカリが飛んでる光景に参加者が若干引いてしまった場面*9もありましたが、様々な言語のテストケースを次々に見るという経験はそうすることもなく、非常に楽しかったです。

私のペアも、マサカリに対する恐怖を覚えつつ、レビューセクションで発表する機会を期待していたのですが、残念ながら漏れてしまい、マサカリは体験できずに終わりました :)。

ふりかえり

ペアプロ終了後に、KPT によるふりかえりが行われました。

写真は取り忘れてしまったのですが、私も含めまして、みなさん講演やペアプロに大変満足されている様子でした。

LT 大会

懇親会フェーズでは LT 大会が行われましたが、プレゼンターのみなさんが大変濃厚で、笑いつつも大変勉強になりました。 Groovy かっこいい自慢、vim による ruby の TDD ライブコーディング、Grails 用の jasmine テスト実行プラグイン、本当にあった怖いテストケース、IDEショートカットキー対決（？）、etc…。

収穫

一日を通して、自分の中で大きな収穫だったと思えるのは以下の点です（再認識した点も含む）。

  • テストコードが無いプロダクションコードはレガシーコード
  • テストメソッド名に期待される振る舞い（○○の場合××となるべき）を書く
    • いままでパターン（○○の場合）しかメソッド名に書いてなく、書こうとしたらすごいとてつもなく長いメソッド名になりそうで指摘をうけた時点ではあまり釈然としなかったところでもあります。
    • が、「メソッド名に書けないほど期待される振る舞いがあるのなら、それはメソッドの責務がでかすぎる」という指摘で、確かにそうか、と気づかされたところです
  • TODO リストによるテストケース作成
  • git now 便利！
    • このブログは、ローカルで markdown で書いてから投稿してるのですが、そこで早速 git now しまくってみました
  • TDD では、黄金の回転をするためにがんがんローカルコミットしたほうがよい
    • テスト実行して通ったらコミットするような半自動コミットもあり
    • git now とかで余計なことを考えずどんどんコミットして、後から rebase して push するのもおすすめ
    • リファクタリングする前にコミットしよう
    • Subversion でもテスト通ったらコミット、は使えるよ
      • けど、コミット粒度が大きくなるしコミットの心理的障壁が大きいから、 DVCS がおすすめ
      • Subversion は正直××
  • 実行時間がかかるテストは効率を悪化させるし、ひどいと消される運命にあるからどんどん実行時間のかかるテストは改善すべし
    • テストコードのプロファイルを取って調べるのがおすすめ
    • Jenkins で自動的にプロファイル取るようにするといい
    • 自分の携わっているプロジェクトでも、Jenkins に通したら全プロジェクトのテスト走行が終わるまで1時間近くかかるという現状があり、明らかにこれは効率を落としているので、まずはプロファイルを取るようにしてみようと思うところです
  • Groovy は Java のプロダクションコードを置き換えるには向かないが、Java のプロダクションコードのテストコードを Groovy で書くのはかなり有効なのでおすすめ
    • LT 大会での Groovy 自慢で目にしましたが、かなりテストコードの柔軟性が上がり、かつわかりやすいと思えたので、個人的にまずは試してみようと思うところです

最後に

大変楽しく、また勉強になり、TDD を実践してみようと思うに至りました。 TDD エキスパートへの道のりは遠いですが、少しずつ皆さんのレベルに近づいていこうと思う次第です。

また、今回の勉強会を開催していただいたことに、運営の皆さんに感謝申し上げます。

*1:チーム開発で共有してるソースコードでは嫌でも書きますが、自分しかメンテナンスしないような単発スクリプトとかだと省いてしまうことがあります

*2:もちろん、それに近いようなことを頭ではイメージして実装するわけですが

*3:後の補足で、この方法が正解というわけではなく、時間で切るといった方法もあり、ペアのやりやすい方法を見つけるのが良い、と説明もありました

*4:Java をメインで使っている身で有りながら、このようなバージョン規則になっているとは知らず、少し恥ずかしく思ったりもしました

*5:若干記憶に自信がないので、時間は間違ってるかもしれません

*6:PHP での参加者が私を含めて4人でしたので、予想よりはだいぶ少なかったです。人数でいうと Java > Ruby > JavaScript > PHP > C++ ≒ Grovy だったと思います。

*7:若干自分がドライバー時の占有時間が長くなってしまったのは申し訳なかったです

*8:つまり、モデリングや、言語特有のメソッドの命名規則を無視したサンプル

*9:私個人の印象