TDDBC 仙台 the 3rd に参加しました。#tddbc
先週のTDDBC横浜3rdの熱狂も冷め切らぬうちに(あれがまだ1週間前の出来事とは思えない)、TDDBC仙台 the 3rd に一般参加者として参加させてもらいました。
場所は違えどTDDBCはやはり大変熱いイベントで、楽しかったです。スタッフの皆様、参加者の皆様、会場を提供してくださったデータコム株式会社様ありがとうございました。
横浜3rdとの違い(言語編)
横浜3rdは、需要?人気?のある言語(JavaとRuby)の参加者さんが多かった印象(全体の1/3がJava, 1/3がRubyくらい)だったのですが、仙台 the 3rdは、色々な言語にバランスよく分散した感じでした(C#, Ruby, PHP, Java, Python, Objective-C,Groovy, Kotlinだっけ?漏れてたらすみません...)。
なので、コードレビューは「いろんな言語でのユニットテストの作り方」が眺められる感じの内容でした。横浜ではサポートできなかった言語の話が聞けたのは良かったです。特に興味深かったのはObjective-Cチームのコードレビューでした。(多分9月に)新たに公開されたXCode5.0系でサポートされたテストフレームワークを使ってテストを書かれていて、1つのテストメソッドの中で複数のassertを記述した時の挙動が興味深かったです。xUnit系の伝統?では何か1つのassertが失敗したら、以降のassertは評価せずに「テスト失敗」と扱われていたのが、このテストフレームワークでは全てのassertが評価されてその上で失敗していたassertが何か表示されるようになっているそう。
横浜3rdとの違い(課題編)
課題はすでに公開されているので興味のある方は devtesting を覗いてみてください(10月14日にメンテが入るそうなのでしばらく繋がらないかも)。
この課題のミソは、最初は課題1しか公開されておらず、課題1をクリアしたら課題2が公開されて…というスタイルを取っていたことでした。そうすることで課題1だけでの最小限の実装と、課題2に取り組む際の最低限の実装に相違と重複が発生するのでそれによってリファクタリングが必要になってくる、という非常に良い課題でした。 Rangeオブジェクトをサポートする言語ではRange使用禁止の縛り、の前提があったとはいえ、実によく考えられて作られていた課題だな〜と感心することしきり。
自ペアが取り組んだ事
今回は、Groovyで参加することになりました。で、同じく首都圏から参加を表明していた @terahide27 さんとTDDBC仙台 the 3rd 前々日にお会いした時に「プロダクトコードはJavaで書いて、テストコードはGroovyで書くと、会場にいらっしゃるJavaで参加されている方にGroovyの魅力が伝わるんではないですかね〜」のような会話をしていました。
まさか本当にペアプロするとは思ってなかったのですが(w)、そうなったので実際にプロダクトコードをJavaで書いて、テストコードはSpockで書いていました。
JavaのコードのテストがGroovyで書けるよ!を実践したのは良かったと思うのですが、反省点としてはGradleを使ってテストを実行していたことです。今、Javaのプロダクトコードにテストが無くて困っている・書こうとしている環境ってきっと、AntやMavenを使っている環境の方が圧倒的な気がするので…。
共有したコードは github にUPしました。(次にペアプロする時は開発中からgithub使おう…)
今回の反省
二度寝してしまって、新幹線の時間に間に合わんくなってしまった(´Д⊂ヽ
— あさの (@uasano) 2013, 10月 11
3連休初日の午前中で指定席が空いていなかったから、朝早い時間のはやぶさグリーン車の切符買ったのに!