TDDBCに参加しました
TDDをペアプロで経験できるTDD boot campに参加してきました。
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C
存在は知ってはいたものの、参加する機会はありませんでしたが、参加しているyokohama.rbでスタッフ募集があったため思い切って参加することにしました。
その後で聞きましたが一般参加枠は募集後数時間締め切り、今回は抽選になるという人気イベントだったそうで…スタッフで参加できたのは幸運でした。
今会社で使ってるJavaにしようかと思いましが、一応スタッフなので奇数のRubyに参加しました。
詳細レポートは様々な方が書いているので簡単に感想と気づきを。
特にshinyaさんのレポート充実し過ぎワロタw
http://d.hatena.ne.jp/absj31/20111105/1320547155
なおTDDについては入門記事等で概要は把握して、UnitTestは場合によって書いてる程度で、TDDレベル的にはまさに新兵です。
感想
- ペアプロ楽しい！
@kotakanbeさんとペアプロしました。Javaメイン、Vimmer、英語キーボード、Rubyの使用はツール作るレベル、Rspecほぼ未経験…とびっくりする程私と同じ状況ながらコードを書くとやっぱり全然違う発想をしてたり…色々発見がありました。おかげさまでどうにか用意さらた課題6問クリアできました。@kotakanbeさんありがとうございました！
- 多言語での参加、レビューが面白い
JavaScriptやC++、果てはGroovyのテストまで。異文化のテストコードがとても興味深かった。
特にGroobyはRubyと比べてもとてもすっきりしたテストコードで驚きました。spockというテストライブラリを使ってるそうです。
http://code.google.com/p/spock/
気づき
- テストは日本語を使うのをためらわなくて良い
Java,PHPのように許されるなら関数名に日本語をける事もアリ。
- 一旦失敗させる意味
Red→Green→Refactorのサイクルで一旦Redにする意味がずっと腑に落ちなかったが、「テストのテストをしている」という事で納得。
- 学習テスト
今回の課題にあった四捨五入とか、ちょっと調べればわかるけど、覚えていないものをテスト化しておく。
テストする事によって覚えやすくなるし、使い方の理解も深まる。
- テストデータ選定
実データ、もしくは近いデータを使うのは重要…だけど、境界値等レアケースのテストは抜けている事が多いので注意。
- テストクラス内に入れ子を使って管理すると良い。
Rspecでできるのは知ってたけど、java JUnitでも static classを使う事によってクラス内に入れ子を作れる。
- パラレルチェンジ
テストの変更が必要な大きいリファクタするとき、テストと実装同時に変えると変化が大きすぎて危険。
じゃあどうするか？
古い実装、テストを残しつつ新しいテスト、実装を書き、両方通るようになって初めて古いテストを消す。
…うーん、理論は納得しつつ、両方通るようにするときに余計なコストかかるときどーすんだろ？とか、若干疑問は残った。
しかし、理念としては「変更を小さくする」事で安全に開発する事だと思うのでそこらへんは臨機黄変で良いのかなという理解にしておく。
- パラメタライズドテスト
テストの実行を共通化して、データのインプット、アウトプットの組を複数作って冗長なテスト記述を避ける手法。
JUnitでもできる。
@shuji_w6eさんのサンプル
https://twitter.com/#!/shuji_w6e/status/132731935083593730
注意点としてはどこでエラーが起こったかわかりづらいところ。データ内にテスト名を含める等工夫が必要。
- テストしやすくする為に実装を工夫する。
テスト結果がわかりづらい時に、実装に本来必要無い名称データを入れる事によってログを見やすくした。
恐らくこの事によってログも綺麗になって運用時にも役立つと思う。
- ぺけま
せとあずさ♂(@setoazusa)さんが「るびま」にあやかって作ったウェブ雑誌。xUnitについての情報が載るようで期待したいです。
http://devtesting.jp/pekema/
まとめ
多言語開発者が集まるので懇親会も非常に多用なメンバーで日頃の勉強会と違った楽しみもありました。
楽しいという点、勉強になる点両方の観点で両方予想以上に良いイベントでした。
機会があればもう一回出たい！ そのときにはTAで参加できるようになっておきたいものです。
実際の業務で使いこなせるよう頑張ります。
