TDD Boot Camp 横浜 Second Seasonにスタッフとして参加してきた #tddbc

勉強会 TDD



去年夏の東京1.6、秋口の横浜に引き続いてのTDDBC参戦。


開催会場は株式会社アットウェア＠横浜。毎度お馴染み『アジャイルサムライ読書会 横浜道場』の場でもありますね。


今回はスタッフ/TAとして参加していたというのもあり、早め(8:45)に会場入り。諸々の調整、準備等をしているうちにあっという間に受け付け開始の9:30に。(※ちなみに当日はいっしょー(TwitterID:@1syo)さんと2人で受付業務を行っておりました。


受付以降も何だかんだで色々動き回っていたのもあるので、今回のレポートについては一部を除いてつぶやき／写真付きつぶやきが多めです。ざっくり振り返りつつ、内容についてはつぶやき／写真で展開して行こうと思ってますので寄り詳しい内容は併せてエントリされるであろう多くの参加者のブログや各種資料を御参照頂けると幸いです。


前回参戦(TDDBC横浜)〜今回の参戦(TDDBC横浜Second Season)までに行われたTDDBC関連イベント

…とその前に、毎回ブログエントリでまとめているシリーズで今回も前回までを総括。今年は6月辺りから怒濤のイベントラッシュでした。直近も仙台(8/11)→岡山(8/25)と割とタイトな実施日程。


前回横浜1.0から今回のSecond Season(横浜はこの後のナンバリングどうするんだろう…)までに開催されたTDDBC関連イベントは以下の通り。

はじめに (10:00〜10:10)

TDDBC横浜シリーズ主管、せとあずさ♂さんと会場ホストのKIMURA Takao(TwitterID:@tw_takubon)さんによる挨拶から。


基調講演 (10:10〜12:00)


かわにしさんによる基調講演。書籍『テスト駆動開発入門』をベースにした内容でした。(※スライド資料は公開され次第リンクします)




基調講演中、突如一斉に鳴り響く音、音、音。何事か？と思いましたが、こういう事情のようでした。




ペアプロ・TDDデモ (12:00〜12:30)



TA/スタッフはこの時、基本部屋の後ろに陣取ってました。

そしてお昼休みを前にグリーンバンド販売についての軽い説明が和田さんからありました。

そのままお昼になだれ込み、お昼休み中にグリーンバンド販売も実施。トータルで35個近くは売れていた模様。このタイミングで販売する事で会場はグリーンバンド一色に。(※注：グリーンバンドでは現地(開催会場)での『実費での配布』となっております)

TDD＆ペアプログラミング実習／コードレビュー (13:15〜18:00)

昼食後はいよいよイベントの肝、ペアプロTDD実践＆コードレビューのサイクルに。

Javaで選択した人数は今回最も多かったので、Java(JUnit)テスティングに自信のある／無しで一列に並んでもらい、両端同士でペアを組んでもらう形を取り、ペアを作成。


その他の言語及び当日の座席表、席位置はこんな感じでした。

  • (注：座席表位置は【ペアプロ第1・第2セッションでの座席位置】午前中は講演ベースだったので席はバラバラでした／第3セッション目にはこの状態から更にペア交代を行っていました)。
  • (注：Java及びRubyでの参加者の座席位置が把握出来ておりませんでした...orz 自分はココに座ってたよ！とかこの人はココに座ってた、と御存知の方は是非修正をお願いします。ドキュメントは誰でも修正可能な状態にしてあります)
  • TDDBC横浜 Second Season 座席表 - Google Docs

エントリ冒頭にも書いたように、私自身はTDDBCに過去2回参加者として参加しています(共にJava)。なので、さすがに3回目は(ちょっと参加者で参加するのはねぇ…／もうTAやスタッフとして関わるべきだろう)…という思いもありました。また、TDDBC参加後もBootはしたもののBoostしてるか？と問われると疑問符が付く所もありました。そんな経緯もあり、TDDBC横浜2nd開催が決定から少々経った時期にある種『イベント駆動』で関連するテーマへの学習を促進させよう！と今回のTA/スタッフ参加に手を挙げてみた感じです。


TA目線で他のTAの方々を眺めて見ると、やはり皆さん素晴らしい知識や振る舞いでペアに適宜的確な助言やアドバイスなどを送られていたり、テストに関する独自の見解や意見なども持っておられたり。色々な気付きや学びを得られたひとときでした。(主に)Javaで参加された皆さん、当日は如何だったでしょうか？楽しめていただけたのなら幸いです。


これまでのTDDBCに於いてTAの方々は皆歴戦の強者揃い！といった顔触れで若干TAエントリに手を挙げるのは『大丈夫かな〜』と躊躇いもありましたが、TDDBCや関連イベントに参加され『是非自分も！』と触発されたのであればその勢いを大事に手を挙げてしまっても、まぁ大丈夫なんじゃ無いでしょうか。既に所定の言語でのテスティング経験が十分にある人は勿論の事、イベントを体験したけどその辺のスキルはまだ…という方も、参加された事で既にまだ参加していない人よりは1歩前に進んでいるわけで、その際の思いや振り返り、経験を踏まえて次回以降参加される方々に助言やアドバイスされる事でも務まるのではないでしょうか。(※あ、対象言語及びその言語で推奨・指定されているテスティングフレームワークはマスターまでは行かなくても、そこそこ把握し使える事は勿論必要ではあると思います。あと、参加者の体(てい)で強力なマサカリを投げてくる強者も紛れ込んでくる事も多々あると思いますのでその辺りには注意が必要になるかもしれません)


なお、課題に関しては最近行われているTDDBCで良く採用されている『自動販売機2.0』を横浜2ndでも採用。課題として利用されている頻度が多い事もあり、『用語集』など補足情報も用意されている参加者にはありがたい課題に熟成されておりました。

個人的にもこの日を迎えるにあたり、事前に途中(Step5)まで予習をしてみました。今回のイベントでのレビュー指摘内容を踏まえると、TAなのにこんな出来で大丈夫だったのだろうか…と若干不安ではありますが、晒しておきます(笑) たぶん指摘個所だらけだろうとは思うので、改めて内容を見直しつつ、空き時間を使って最後までトライしてみようと思います。


実践内容やコードレビューの詳細については参加者の方々が各々振り返ってブログなりに上げてくれると思うのでそちらにお任せ。ここではTA/スタッフの傍ら撮っていた写真の数々(及び参加者のつぶやき)で当日の雰囲気を感じ取って頂ければと思います。

ペアプロTDD実践





関連書籍


コードレビュー



質問コーナー (18:00〜18:30)


ペアプロTDDの時間内までに寄せられた質問に、主にTA(参加者も含む)が回答して行くと言うコーナー。

今回のイベント中、唯一メモを取れたのがこのコーナーのみだった(笑)という訳で、こちらは可能な限り書き留められたメモをUP。

回答の中で記載に指摘事項がある場合は教えてください。対応致します。
  • Q.コードが変更されたら、テストを直さないといけなかった。これはしょうがない？
    • 変更ならばしょうがない。
    • 原理的にはテストを先に直すべき。
    • 変更によってどう振る舞うかどうか分からない場合は仕方無い。
    • 実装側にテストが寄ってしまってる際におきがち。
    • コアなドメインクラスを変える場合グリーンtoグリーンとは行かない。
    • やっぱり落ちるケースはある。
    • テストの粒度が複数ある(より画面やWebに近い場合等)
    • ユニットテストだけでテストやると怖い。
  • Q.JUnitでRSpecのように状況・機能で分類する方法はある？describeのようなやつで。
    • JUnit4ではEnclosedというアノテーションで状況毎のテストを書ける。
    • Eclipseで開発の際、複数まとめて実行する際の注意点がある。Suite絡みで。
    • 実行方法はあるけど、まぁ面倒臭い。
    • テストコードをgroovy/gradle等に任せるという方法もある。
  • Q.シナリオ的なものはどこまで考えるべき？
    • 目処を立てて作る
    • ユニットベースでの機能単位で考える
    • 最終的にはエンドツーエンドだけれども
    • シナリオ、とは何なんでしょうね？
      • 今日のお題：払い戻し操作、2回目はゼロである。というシナリオ
        • 行間にあるところをどこまで読むか。
        • ユーザーストーリー？
        • 身もフタもないけど…わかるじゃないですか？(笑)その分かるを、どこまで明確にするか？
        • 何もかもPOに聞けと言われたら、そらPOキレますよ
      • 対象とするものがちゃんと書ける
      • それこそ、ドメイン知識なのではないか。
      • 動かしてみてから、分かった段階で
      • テストする、という価値判断をどこに持つか。
      • テストケースの選びかた、という所に行くのでは。
        • 自動販売機は一種の状態、入力の
          • 気付いたものを手当たり次第テスト、はムダが多い。
          • テストの意味合いを失わせない範囲でテストを作成するのがテスト戦略。
        • そういう状態に気付く事が多いケース：コンテキストを絞っていく
          • ネストが一段深くなる場合、デバッグで一旦止めるイメージ？上手く説明出来ないけれど。
        • 特殊な状態に気付きやすい書き方をする事が多い。
          • そういう思考モードに至り安いように、テストを書いていく。
        • テストのネストが深くなる度に1：1で考えられるような書き方。
          • 自分で気付きやすい書き方を心掛ける。整理して考えられるように。
  • Q.テストケースを考えてみた時にそれをリストに出してみると細かい点が出てきた。それらテストの『実行順序』という点を考えると、どういう順序で書くのが良いのか？
    • テストするケースを考えた場合、どういう順序で書く？
    • 状態が初期値の状態で
      • 10円入れた状態で
      • 1個書いた段階で気付くテストもある、そういう時に順序はどうする？
    • テストメソッドの名前で意味を表している。
    • まずは一旦テストメソッドで枠を書いてしまう。一覧。そしてignoreにしといて順次対応、ignoreを消していく。
    • このメソッド要るな、と分かったらペンディング状態にしておいて後で対応。
    • todoで消す、というというのもあると思う。
    • 一旦ガーッと書いておいて。
    • 状況を増やす方が安価なのか、機能を増やす方が安価なのか。悩ましい問題。
    • すぐ手を出すか、後で手を出すか。すぐ脇道に逸れやすいので、控えておくと言うのは良い。
    • テストリストというのも、そういう側面があると思う。
    • 機能増やす方が、コストが高くなりがち。
  • Q.git commitのタイミングはいつが適切でしょうか？git-nowも使いますか？
    • 手で動かす時代は終わりました！
    • auto-commitをオススメします。歴史を再編集するという手法。
      • 最後に終わってからコミットコメントを考えるので良い。
      • 便利そうだけど面倒臭そう？
      • だいたい10コミットが1つになる粒度。
    • git-nowを使っています。
      • git-nowも忘れるというケースもある。コミット感覚が空く場合
    • gitでマスター上で作業するというケースはまず無い。ブランチを切って作業するのが普通。
    • greenになった段階でコミット。赤い時点でやると同僚に怒られる。
    • リファクタリング：綺麗にするのは意外に手間が掛かる。戻れる様にしておく／戻れる地点を作っておくという事は価値がある。
  • Q.『納品に間に合わない！』テストを書かないとダメ？
    • スピリチュアルというよりもポリティカルじゃね？
    • 答えは無い。
      • これだといつまで経ってもテストを書かなくなる。
      • 書けるところから少しずつ書いていく事で、テストが上手くなる。ポカが減ってくる。
    • システムテストでぬるぽが出るようなケースは減っていくはず。
    • 基本人間は損得で動くので、『テストを書く方が得』という方向に持って行く方が吉。
      • 後で書いても良いんだよ。
  • Q.『時間がない』『リリースが近い』事を理由にテストを書かない人を戒める方法を知りたいです。
    • とあるスゴいバグを起こした。みんな怒られる。痛い目を見るとみんな言う事を聞く。
    • （うちも大分痛い目見てる、辛いと思うんだけどな〜という声多数）
    • 手動テストの項目が10000を超えているというところも…
      • 自動化することでどれだけ効率化出来るのか？というのを再確認
      • 4回テストをやるくらいなら、自動化すべし。
    • リリースする直前にリファクタリングしてはいけない、というのはある。
    • 言ってることは分かるけど、書いてる暇はねえんだよ！というのをはじく仕組みは難しい。
  • Q.テストがあれば安心して作業出来るのは分かるけど、現実には時間もお金も有限、どうすれば良い？
    • A.基本的には今の開発だとテストが無いとリジェクトされる。そういう仕組みが無いと書けないという心理状態になった。
  • Q.TDDの1ステップが大きすぎると感じた時、設計中でしか使わないメソッドを追加して進んで行くのはアリでしょうか？(プロダクトコードではそれは削除)
    • 途中で確認がしたくなった。メソッドを作って最後に消す。privateにする
    • 1個がデカ過ぎると1サイクル回らない
    • 途中経過を見ると言うことが副作用を与えないのであれば、構わないのでないか。寧ろ推奨？
    • オブジェクト指向的な考えで行けば、小さいメソッドを作って…というのはあり。
    • デカイ事はフィードバックになり得るのではないか？
  • Q.実装してる時に気づいた新たなTDDの管理方法や、やるタイミングについて、オススメな方法などがあれば教えてください！
    • べただけど、テキストファイル。
    • コードの中のコメントでフィルタリング的なもの。TODOなど。それを集める。
    • エディタから離れたくないというのもあるだろうし
    • Emacsにはスクラッチバッファ。
    • テストケースで『＊＊になって欲しい』というのを書く場合がある
    • テストコードで一番近い所にTODOコメントを書く場合がある。
    • 普通に紙。
      • 話題を見ながら並べる事が出来る、画を描くことも出来る。管理はめんどいけど。短期間なら効率的。
    • 普通にやることの管理なのかな〜と。
    • Evernoteや付箋紙など。
    • 紙をPDFで取っておく。
    • jenkinsにカウントさせておく。タスクスキャナプラグイン。

ふりかえり・クロージング (18:30〜19:00)

目立った所としては、『質問コーナーが良かった』等でしょうか。突発的に思いついてこのコーナーを設けたらしいのですが、参加者の疑問に時間を置かずに回答が得られたのもあって好評だったようです。

ふりかえり内容については以下に文字起こし致しましたので宜しければ御参照ください。


そして最後は全員集合写真撮影で締め。ちょうどこのタイミングで懇親会用食料の宅配が到着していたので撮影をお願いしていましたw

懇親会 (19:00〜)


時間的には大きな遅れも無く、ほぼ定刻通りに懇親会に突入。そして午後8時を回る頃にはLT大会へと突入。

LT：『今の現場がこんな風だ』


LT：『ジョジョLT的なもの』


LT：『cucumberとseleniumでFacebook HEROになる』



LT：『Goos本翻訳版のお知らせ』


実践テスト駆動開発 (Object Oriented SELECTION)

実践テスト駆動開発 (Object Oriented SELECTION)

LT：『RSpecに関するパッチを(TA業の傍ら)書いていたお話』



そして引き続き懇親会は続きます…(※この後とあるトピックで懇親会会場が多いに盛り上がっていた(一日を通して、本編のどの場面よりも遙かに盛り上がってた！)んですが、寝て起きて冷静に考えてみるとアレだった(熱量は半端無かったけど方向性がドイヒーw)のでこちらのエントリで言及するのは自重します(笑) 詳細を知りたい人は参加者に直接聞くか、Togetterを見てみよう！)


以上、TDDBC横浜2ndに御参加の皆様、お疲れ様でした＆ありがとうございました！


その他関連：