TDD Boot Campに参加しました

プログラム

ブログを書くまでが(ry

IMG_1537 iPhone 4 (3.85mm, f/2.8, 1/15 sec, ISO500)

先週土日でTDD Boot Camp Fukuokaに参加しました。
http://tddbc.doorkeeper.jp/events/3472
TDD(テスト駆動開発)の基礎をブートキャンプ形式で土日2日間にわたってペアプログラミングを通して勉強しました。

参加したきっかけはAIP Cafeで先月行われたGit Hubハンズオンに参加した時@Spring_MTさんが紹介して、面白そうだと思ったから
その前からTDDはじめアジャイル開発には興味はあったけど、身近にやっている人いないから始める切っ掛けが欲しかったのでちょうどいいと思った。
そして何より、一応大学を卒業してエンジニアになり2年以上経つが、基本的にひとりプロジェクトとか先輩のいない中「ソースが仕様だ！」みたいな仕事を続けていてこのままじゃダメだと思ったから
今回の経験をきっかけに職場にもまともなプロジェクト開発を持ち込みたかった。

まず初日目、実践に入る前に@t_wadaさんの説明
一応、TDDいきなりやるのは怖かったので和田さんの以前のSlideShareの発表やネットでの情報を調べていたのである程度すんなり飲み込めることができた。
とても参考になる話が多かった。
少し内容は変わっているが大体下記のとおりである。

説明の後、実際にペアを組んでTDDを体験してみた。
一応Javaが一番得意なので、Java+JUnitでやってみた。

テスティングツールって言ったらJUnit有名だし、Javaer多いのかなって思ってたんだけど、以外にRubyが一番多くJavaは3人しかいなかった。
事前のアンケートにはもっといたので他の言語に入っただけの人もいるだろうがちょっと意外だった。
まず、郵便番号のバリデーターの実装が課題だった。
ここからはTDDの実践って感じでした。
まずTODOを列挙して、テスト項目を作成
JUnit使ったことないので、JUnitの使い方から調べて(岸田さんが教えてくれた)、テスト→失敗→実装→成功→リファクタリング→……
な流れを実際に試してみた。
ちなみに岸田さん直伝のJUnitのテストコードの書き方はassertThatを使って次のように書く。
普通ならこう書くところを

@Test
public void 数字が3桁ならOK(){
assertTrue(sut.validate("123"));
}

こう書く

@Test
public void 数字が3桁ならOK(){
assertThat(sut.validate("123"), is(true));
}

これだけじゃ良さがわからないけど、importするパッケージが少ないのとメソッドのオーバーライドがないため予測候補が少なくコーディングが楽なのと、is()が糖衣構文なので読みやすい。(is(not(“abc”))やis(equalTo())のように英語として自然で読みやすくなる)

まずは自分がドライバーをして、ペアの人にナビゲーターを努めてもらった。
いくつかTODOを消化したあとドライバー交代した。

一つ一つは単純なTODO(英数字なら失敗など)なので簡単なのだが、テストの順番によってあとから大変になるから、そこら辺も考えないといけないのか…
意外と時間をとってしまい、なかなか実装が進まない中時間が来た。

今回、横着して正規表現は使わずInteger.parseIntメソッドを使って数字の判別を行なっていたが、途中で岸田さんに「それじゃ-123みたいなデータも通してしまうから、こういう使い方するときは元メソッドの動きをちゃんと調べるように」とツッコミを入れられた。
正直何も考えてなかったｗｗ

初日目に思ったことは

  • TDD意外と簡単やん
  • JUnitの使い方も全然難しくないやん
  • 技術の食わず嫌いはいけないね
  • ペアプログラミングでナビゲーターなのに必要以上にくちだしてしまう
  • でもやっぱりわかりきっている仕様をすぐに実装しないのはもどかしい
  • GitHub使ってるペアいるな(自分たちも使えばよかった)
  • それぞれのPCがMacとWindowsなので自分の環境でコーディングできたほうが楽だな

こんなかんじでした。

このあと懇親会に行き、みんなで気持よく飲みました。
西プロ参加者が固まっていたので少し勉強会絡みの話とかしつつ、他の参加者と交流。
学生の参加者もいて、みんな頑張っているんだなぁと

2日目は1日目の内容を踏まえもう少し複雑な課題が出てきた。
そしてペアも変え(希望するなら言語も変え)課題に取り掛かった。
結局Javaはペア買える人がいなかったので前日と同じチームで頑張った。

2日目の課題はWikiのエンジンの実装
下記の文法を実装することだった。
https://code.google.com/p/support/wiki/WikiSyntax

今回もまずTODOを列挙
Wikiの書き方なのでわかることもあれば、複雑なものもあるし
テーブルの実装とかは後回し
とりあえず、boldやitalicなど単純なものから実装
一応GitHubでリポジトリを作る。
しかし、ドライバー交代でペアのMacにPullしたら、eclipseの設定ファイルのせいかうまくインポートができずJUnitが動かなかった。
時間もないので結局自分のPCオンリーで前日と同じようにコーディング。
しかし、いつもなれない作業をするせいか、Gitにcommitするのを忘れる。
一応テスト作成時と実装時にコミットするというルールにしたが全然守れてなかった。

実装していくと同じタグを囲む処理なので似たようなものが多数出てくる。
4つ同じコードが出てきたあたりでTAの方が「処理が増えてきたからリファクタリングした方がいいよ」とのことなので処理を修正。
この途中でタイムアップ

2日目の感想は

  • 1日目より深くTDDできた気がする(きがするだけ)
  • ドライバーとナビゲーターの交代のタイミングが難しい
  • 頭のなかに処理が思い浮かぶとそのまま実装するタイプだったのでTDDをするには意識的にしないとすぐ手を抜いてしまう
  • GitHubちゃんと使えなかった
  • JUnitが赤から緑になるのがいい
  • 一度失敗させて正しい動きを記述するっていうのは自分が普段やっているコーディングの時も自然にやっったりする(新規ロジック作る時はあえて空のロジック作って走ることを確認したり)やりやすい！
  • 時間がない
  • もう終わってしまった(もっといっぱい学びたかった)

と言った感じです。
やっぱりTDDとは別にしても仕事でもロクにバージョン管理していなかったのでコミットする癖がついていない。
プロジェクト開発をきちんとしていないため手順を追って作業するということが難しい。
こんなかんじです。
これからはとりあえずTDDは一人でもできるので、趣味開発で実践しつつ仕事でも使えるようにして行きたい。

勉強していくことは多いけど頑張ろう！

@Spring_MTさん、@t_wadaさん
その他参加者の皆さん、お疲れ様でした＆ありがとうございました。

一応、2日間で書いたものを載せます。

1日目課題
https://github.com/ligun/TDDBC_First
2日目課題
https://github.com/TakatoHonda/wiki

スポンサーリンク

コメント

タイトルとURLをコピーしました