うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

TDD in Actionを開催しました。 #TDDAct

TDD
").prependTo(".entry-content"); } //スクロールを滑らかにする $('.sectionList a').on("click", function() { $('html,body').animate({scrollTop: $(this.hash).offset().top}, 600); return false; }); });

募集ページとか

7月22日 TDD in Action #tddact(東京都)
TDD in Action #tddact - Togetterまとめ

開催経緯

@がTDDBCMLでTDDを見せ合うイベントをやりたいと言っていたのだけれど、いろいろあって流れてしまい。
TDD in Actionという名前で企画し直しました。

内容

募集ページ引用

おおまかな流れ

  • 可能な限りペアで1日プログラミング(ペア換えはなしで)します。
  • TDDBCで行なわれているような講演の枠はないです。
  • 「50min ペアプロする -> サポーターによる10minライブTDD のあとに 参加者による 15minライブTDD * 3ペア」の2hくらいを3セット。
  • 言語制限なし。出来るだけペアをつくってください。
  • VCSの使用は参加者に任せます。
  • 静的型付け関数型言語じゃなくても大丈夫です。
  • Groovyじゃなくても大丈夫です。
  • EmacsとVimで喧嘩してしまうときは、GitHubとかBitBucketつかって、ペア交代時にマシン毎いれかえましょう。
  • ランチとスイーツを運営から提供します。参加費1500円よろしくです。
  • 懇親会は会場にてビアバッシュです。希望者は参加費2000円よろしくです。

まぁこんなかんじでやったわけですが、結構まったりとやっていました。
前日のJPOUGさんのビアバッシュの余りで発泡酒とおつまみをもらえたのもあり、
一言で言えば「10時からビール飲みながら21時までTDDしては見せ合ったり、テストの是非について意見交換する」ことをしていました。


他の方もブログで書いていますが、「TDDだと思えばなにをやってもよい」というスタイルです。



ちなみに今回のスイーツはHarbs のラムレーズンバターサンドケーキとチョコサンドクッキー。
ここの好きなので、自分が食べたくて選びました。

サポーター

言語のサポーターとして
TDDBCから
@
@
@
が参加してくださいました。
たすかりましたー。

運営的な

今回はかなりの部分を@さんがやってくださいました。自分がもっとやればよかったなぁと後から反省しました。
本当にたすかりました。ありがとうございました。

最初のライブTDD

最初になかやんとライブTDDをやったわけですが、まぁ事前打ち合わせも無く、僕の調子に会わせる感じでした。ごめんね。
あのときにやったことはかなりフランクにやっていたので、実際にはもっと精緻にやるし、デジタルじゃなくってアナログでやることが多いです。
やったことだけをリストすると

  • プロジェクト背景特定 ->実際にはフリーフォーマットが多い
  • アプリの使われ方特定 ->実際にはフリーフォーマットが多い
  • ドメインモデル構築 ->実際にはフリーフォーマットが多い
  • テスト要求分析 ->これだけはマインドマップツールつかうことが多い


これだけやるのに25分つかったけど、あれだけフランクにやっても25分かかるわけで、やるべきことはもっとあるし、精緻にやっていたらあと倍は時間がかかります。
あのときにあげていなかったこととすれば、在庫管理部分をDBに置き換える事って想定していましたっけー？とか。書かれている事を実装しているだけなら、ただのコードパンチャーと変わらないです。言語を楽しむだけならそれでいいんだろうけどね。


まぁ、コード以外のこういうのもバージョン管理する文化になればいいのになっていつも思います。
ここらへんは、まだSCMとかALMという文化が根付いていないのだなぁと実感します。
SVN時代ならまだしも、DVCS時代において、自分の記録を取らないなんてありえないっす。

他の方のTDDを見ていて

RSpecはやっぱり書き易いよなーって思います。一ファイルにどれくらいのテストを書くかをよく悩むのでいろんなFW触らなきゃなって思い直しました。
GitHubPagesを使う事でJSのテストを流すというのは発想の転換だなぁと思いました。素晴らしいですね。
Haskellはよくわからなかったw 話がずれるけど、個人的にはQuickCheckを使ってバグの当たりを見つけるというのが楽ですよねーとは思う。QuickCheckは「性質や期待値を想定してテストする」のではなく「とりあえず実行してみて性質やバグを見つける」のにすごく便利で、ある程度対象が完成してから、「QuickCheckのコードをちゃんと作る」かどうかは好みだと思う。

演習を見ていたら

いつのまにかGroovyが最大勢力になっていた。なんかJavaからGroovy転向が3人もいた。
Groovy人気半端ねぇ。


最後のライブTDD

「手動コミットが許されるのは小学生までだよねー」ということでチケット駆動開発的自動コミットTDDを披露しました。
まえに基底現実第6層でGistにあげていたGroovyスクリプトですね。
やっていることは
ユーザーがGroovyスクリプトを起動するだけで以下のことをやります。

  1. 起動引数のブランチを作成
  2. 数秒毎にファイル変更を監視
  3. ファイルが変更されていたらGradleでビルド実行
  4. ビルド結果が成功したらコメントに"green"、失敗したら"red" でコミット
  5. 引き続きファイルを監視して。。。と繰り返す


ブランチ内での作業が終わったら、スクリプトを終了して、hg histeditでコミットを整理して、マージしてpushして終了。


どんなシステムをつかっているかにもよりますが、スクリプトで出来る限りのことを支援したり、使っているITSにプラグインつくって出来る限りのことを支援するのは重要です。
DVCSのコマンドを打つ事が仕事じゃないですからね。


ライブで見せたのはトピックブランチを作成するバージョンでしたが、compile_red, test_red, green ブランチでやる方法もあります。まぁ別にブランチじゃなくってコミットコメントでもいいと思うんですけどね。
たぶんブランチでやると、hgではできるけど、gitではできないので、汎用的にするならコミットコメントで区別するする方法だと思います。
(hgのブランチはリビジョンが連続している必要がないけど、gitのブランチは連続している必要がある


まぁこの話は LLDecadeでもしますので、興味がある方は見に来てください。

懇親会

@さんが面白い方だとよくわかったのが収穫でした（お
あと、やっぱりなんだけど、前日に引き続いて思ったのは@くんの実力が高い事でした。見習います。

最後に

参加してくださった皆さん本当にありがとうございました。勉強になりました。
そして、二日間一緒にがんばってくれた、@、@、@、@ さんありがとうございました。
会場提供してくださったオラクルさん、毎度のことですがありがとうございました。
今度はSQL基礎勉強会でもやりたいですね。（お