http://tddbc.doorkeeper.jp/events/2904
2013/03/16 TDD Boot Camp Tokyo 2013-03 #tddbc
http://togetter.com/li/473108
はじめに
今回は、JavaかGroovyのTAが出来ればと思っていたのですが、Groovyの希望者がいなかったためJavaのTAとして参加しました。
始まる前に開催予定である長岡の@masaru_b_clさんと福岡の@Spring_MTさんを囲んだランチミーティングにて、TDDBC横浜での経験を伝えました。
いちスタッフとして参加した程度の経験なので、主催者にとって役に立つのかは分かりませんが、スタッフがこういう風に動いてましたよといったような内容であれば参考にしてもらえるのではないかと思い、話しました。
@t_wadaさんのTDDでの講演は、初回での横浜以来なのでTDDをこれから始める自分を振り返ってみて、「今の状態はどうなのか？」「最初に感じたあの感動を忘れていないか」と自問自答しながら聴いていました。
始まる前に開催予定である長岡の@masaru_b_clさんと福岡の@Spring_MTさんを囲んだランチミーティングにて、TDDBC横浜での経験を伝えました。
いちスタッフとして参加した程度の経験なので、主催者にとって役に立つのかは分かりませんが、スタッフがこういう風に動いてましたよといったような内容であれば参考にしてもらえるのではないかと思い、話しました。
@t_wadaさんのTDDでの講演は、初回での横浜以来なのでTDDをこれから始める自分を振り返ってみて、「今の状態はどうなのか？」「最初に感じたあの感動を忘れていないか」と自問自答しながら聴いていました。
TDD・ペアプロのデモ
ペアプロワークショップ from yattom
TDDのデモということで、@yattomさんとFizzBuzzをお題にペアプロをやりました。打ち合わせでは最低限程度の共有しか出来てなかったので、ほぼぶっつけ本番かつペアプロ自体TDD in Action以来久しぶりだったのですが、プロトコルがあったおかげでなんとか出来ました。
個人的にペアプロのいいところは、自分が考えていること相手に説明することで、考えを整理出来たり、相手がどういう思考でそういう考えに至ったのかを知ることが出来るところだと思っています。
TODOリストについてですが、紙でも電子媒体でもペアが合意すればどちらでもいいと思います。
ただし、どちらともどこまで進んだのか、やらないこと、未確定なことなど、その都度メモを残すことを忘れないことが大切だと思います。
あと、運営側の振り返りでも出て来ましたが、全て書きだしてから始めるのは、完璧な設計に陥る兆候だと思います。
個人的にはアジャイルのプラクティスを参考に、タスクの優先順位づけをして最も重要なものが終わった時に、改めてやるべきことや見落としてることなどを洗い出して、また優先順位を付けて続けるのがいいのではないかなと思います。
Boot Camp
JavaのTAでしたが、ペアの振り分けの結果、Mac、JISキーボード、IntelliJ IDEAでペアを組めるのが私しかいなかったため、急遽ペアを組むことになりました。
私達のペアは、話し合った結果dumpの実装から始めました。
dumpを選んだ理由は、他のgetとsetは、中身の確認を行う必要があるので、確認する手段としてdumpを先に実装してから確認しながら行えばいいのではないかと考えたからでした。
個人的には、TDDBCではお題をこなすことに意識してしまいがちで、リファクタリングをどのタイミングで行うのがいいのか掴む機会が少ないと感じていました。
今回のような文字列をフォーマットして出力するという処理には必ずリファクタリングができるタイミングがあるので、あえてdumpを選びました。
dumpから進むためには、内部で値を保持する状態を「setup」で作る必要があるので、コンストラクタに「setup」で生成した値をセットできるようにして、完了後に塞ぐという手段を取りました。こうすることで、リフレクションで内部アクセスしたり、アクロバティックな方法でテストする必要がなくなります。
また、テストを補助するためのメソッドも予めテストを書いてからパッケージプライベートで実装する手段も取りました。
ただしライブラリを作ったりする際はこういったアプローチが出来るのですが、レガシーコードなどを扱う場合はまた別のアプローチが必要になります。
TDDBCでは、参加者層によってはGitHubやBitbucketにアクセスしたことがないメンバーもいらっしゃるので共有される成果物が少ないです。
また、アクセス出来る人達もpushする際には歴史改変したり、最終成果のみpushするので途中経過を見ることが出来ないことが多いです。
今回のお題に似た内容で途中経過が分かるのが、ぺけまにありました。
DVCSに関しては、TDDBCで扱うには時間が足りないので扱われませんが、そちらはSCMBCや各DVCSのコミュニティでの勉強会がおすすめだと思いますので、ぜひTDDBCに参加された方でDVCSに興味を持たれたら探してみてはいかがでしょうか。
今回のTDDBCで印象に残ったのは２つです。
まずは、Javaのテーブルでは「JUnit実践入門 http://gihyo.jp/book/2012/978-4-7741-5377-3?ard=1363786051」があったことです。
事前に打ち合わせなくペアに一つは必ずある状態だったことは、TAとしてもありがたい状況でした。このおかげでコンテキストの共有が出来て、より深い内容の質問されたことでTAをやってて良かったと実感できました。
TDDBCに参加してみたいと思ったけど不安がある方は、「JUnit実践入門」を手にとってみてください。@irofさんがJUnitの依存性で章のカテゴライズをしてくださっているので、参考になると思います。
次に、Scalaのペアの発表に出てきたSpecs2のhtml reportでした。
それに触発されて野良LTでGradle + Spockのアピールを即席でやりました。
話の内容としては、Javaの実装に対してGroovyやSpockでテスト書くといいよ的な話と、Gradle使えばレポートも綺麗ですよという感じです。
私達のペアは、話し合った結果dumpの実装から始めました。
dumpを選んだ理由は、他のgetとsetは、中身の確認を行う必要があるので、確認する手段としてdumpを先に実装してから確認しながら行えばいいのではないかと考えたからでした。
個人的には、TDDBCではお題をこなすことに意識してしまいがちで、リファクタリングをどのタイミングで行うのがいいのか掴む機会が少ないと感じていました。
今回のような文字列をフォーマットして出力するという処理には必ずリファクタリングができるタイミングがあるので、あえてdumpを選びました。
dumpから進むためには、内部で値を保持する状態を「setup」で作る必要があるので、コンストラクタに「setup」で生成した値をセットできるようにして、完了後に塞ぐという手段を取りました。こうすることで、リフレクションで内部アクセスしたり、アクロバティックな方法でテストする必要がなくなります。
また、テストを補助するためのメソッドも予めテストを書いてからパッケージプライベートで実装する手段も取りました。
ただしライブラリを作ったりする際はこういったアプローチが出来るのですが、レガシーコードなどを扱う場合はまた別のアプローチが必要になります。
TDDBCでは、参加者層によってはGitHubやBitbucketにアクセスしたことがないメンバーもいらっしゃるので共有される成果物が少ないです。
また、アクセス出来る人達もpushする際には歴史改変したり、最終成果のみpushするので途中経過を見ることが出来ないことが多いです。
今回のお題に似た内容で途中経過が分かるのが、ぺけまにありました。
TDD Live 番外編(TDD序破Q)Groovy + Spockで書かれていますが、説明が補足されているので分かりやすいと思います。
TDD 序破Qの世界へようこそ!
DVCSに関しては、TDDBCで扱うには時間が足りないので扱われませんが、そちらはSCMBCや各DVCSのコミュニティでの勉強会がおすすめだと思いますので、ぜひTDDBCに参加された方でDVCSに興味を持たれたら探してみてはいかがでしょうか。
今回のTDDBCで印象に残ったのは２つです。
まずは、Javaのテーブルでは「JUnit実践入門 http://gihyo.jp/book/2012/978-4-7741-5377-3?ard=1363786051」があったことです。
事前に打ち合わせなくペアに一つは必ずある状態だったことは、TAとしてもありがたい状況でした。このおかげでコンテキストの共有が出来て、より深い内容の質問されたことでTAをやってて良かったと実感できました。
TDDBCに参加してみたいと思ったけど不安がある方は、「JUnit実践入門」を手にとってみてください。@irofさんがJUnitの依存性で章のカテゴライズをしてくださっているので、参考になると思います。
JUnit実践入門の感想とJUnit依存具合と読書会と #junitbook
http://d.hatena.ne.jp/irof/20121123/p1
次に、Scalaのペアの発表に出てきたSpecs2のhtml reportでした。
それに触発されて野良LTでGradle + Spockのアピールを即席でやりました。
話の内容としては、Javaの実装に対してGroovyやSpockでテスト書くといいよ的な話と、Gradle使えばレポートも綺麗ですよという感じです。
おわりに
今回のレポートもこちらにまとめられているので、TDDBCに参加したいけど東京は遠い、でも長岡や福岡なら近いと思われた方や次回参加してみたいと思われた方は、参考にしてみてはいかがでしょうか。
主催してくださった@katzchangさん、講師の@t_wadaさん、TDDBCのスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社VOYAGE GROUP様ありがとうございました。
TDDBC Tokyo 2013-03 の参加レポートたち #tddbc
http://matome.naver.jp/odai/2136365798061279801
主催してくださった@katzchangさん、講師の@t_wadaさん、TDDBCのスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社VOYAGE GROUP様ありがとうございました。
