タグ別アーカイブ: tddbc

Xamarin向けC#+NUnitのスケルトンを作りました #tddbc

TDDBC for C# with NUnit on Xamarin Studio

MSTest用のスケルトンはすでに作ってありましたが、NUnitのスケルトンはまだ作ってなかったので作りました。対象はXamarin Studioです。

MonoDevelopでもたぶん動くんだとは思いますが、環境がないので未検証です。

XamarinでTDDBCに参加される奇特な方は、是非ご利用ください。

#tddbc 長岡 1.0の演習をC#でやってみた – @masaru_b_cl

Javaの奇妙なバージョン – C#

 

ポイント

  • テスティングフレームワークはMSTest
  • サポートライブラリにChaining Assertion
  • テストケースにはカテゴリーを付け、partialクラスを用いて複数ファイルに分割
  • Versionという名前はSystem.Versionクラスで予約済みなので、JdkVersionに変更
  • JdkVersionはイミュータブルなValueObjectとして、structとして定義

 

というわけで、遅ればせながら演習をやってみています。

 

チャレンジングなこととしては、テストケースにカテゴリを付け、カテゴリ毎にpatialクラスに分割して記述しています。

image

image

 

テスト実行結果はこんな感じ。VS2012 Update 1の追加機能である、カテゴリごとのテスト結果表示を行っています。

image

 

分割したファイルをグループ化するには、*.csprojを直接編集して、対象ファイルCompile要素の中に、DependUpon要素として親となるファイルを指定するだけです。

 

VS2012 Pro以上ならば、VSCommands拡張を使って、GUIで簡単にグループ化できます。

image

 

まとめ

VSCommandsおすすめ!

#tddbc 長岡 1.0を開催しました – @masaru_b_cl

TDD Boot Camp 長岡 1.0 – TDDBC

TDD Boot Camp(TDDBC) – TDDBC長岡1.0

TDD Boot Camp(TDDBC) – TDDBC長岡1.0/演習

TDD Boot Camp(TDDBC) – TDDBC長岡1.0/KPT

 

5/18(土)に「TDDBC 長岡 1.0」を開催しました。

お集まりいただいた参加者の皆様を始めとして、講師として駆けつけてくださった@t_wada、TAとしてお手伝いいただいた@kenchan@setoazusa@ktz_alias@megascus@a_suenami、並びにスタッフとしてご協力いただいた@civic@dictav@ishiduca@yu_hori@hiro55bs、本当にありがとうございました。

 

TDDBCとしてのふりかえりは、TDDBC Wikiを見てもらうとして、このエントリでは「イベント主催者」としての感想を述べていきたいと思います。

 

  • スタッフの協力もありつつがなく終えることができて非常に良かった
    • イベント主催は、「コンダクター」としての立ち振る舞いが求められると感じた
    • 自分でガンガンやるよりは、タスクの明確化、適度なサイズへの分割、振り分けがメインだった
      • 他の人に委譲可能なタスクを見出すのは難しい
    • 当たり前だが、動かないと先に進まない
      • 動けば付随して何かしらタスクが発生する
      • TDD黄金の回転の、動かない→動くの象限への移動と同じく「気付き」がある
      • イベント発案したら、とにかく動くの大事
      • 必要なタスクが分かれば、人に任せることもできる
  • みんな生き生きとTDD、ペアプロを楽しんでもらえたようで何より
  • 緑川が思いのほか好評で面食らった
  • 地味にうれしかったのが、@t_wadaのサインをもらった人が、非常にうれしそうだったこと

    (きのこ本Tシャツを着て、きのこ本にサインを書く@t_wada)
    • 距離、時間の関係でそういう機会がなかった人に、その機会を提供できた
      • これは事前に想定していなかった
      • イベントを開いた甲斐があるというもの
  • スタッフはNDSで築いたネットワークをフル活用
    • 非開発者含め
    • 助かった反面、参加者として参加して欲しかったというのもある

 

色々とありましたが、まぁ成功と言っていいのではないかと思います。

この調子で、TDDBC 新潟、上越などが開かれるととっても嬉しいですね。もちろん長岡も継続開催の方向で!

 

でも、次は主催は他の人に任せたいなー。キーノートくらいやりますので、誰か燗酒がおいしい季節に企画してくださいw

TDD Boot Camp 長岡 1.0 参加者募集を開始しました #tddbc

TDD Boot Camp 長岡 1.0 – TDDBC

日時
2013/05/18 (土) 10:00 – 17:30

申込期限
2013/05/18 (土) 10:00

参加費

会場払い2,000円

開催場所
まちなかキャンパス長岡 5F交流ルーム
〒940-0062 新潟県長岡市大手通2-6 フェニックス大手イースト4F

参加者
0 / 20人

というわけで、遅くなりましたが参加者募集を開始しました。ふるってご参加ください。

また、TAなどのスタッフも引き続き募集しています。何かしらお手伝いしていただける方は、ご一報願います。

#tddbc Tyokyo 2013-03に参加してきました

3/16(土)に開催されたTDD Boot Camp Tokyo 2013-03 – TDDBCに参加してきましたので、レポートです。

 

ランチミーティング

今回のTDDBCは今年開催予定の福岡、長岡の主催者のサポートという意味合いがありました。そこで、イベント開始前にランチミーティングという形で、TDDBC開催に向けての相談をしてきました。

出席者は今回の主催者である@katzchangをはじめ、@t_wada、横浜の@grimerose、福岡を開催予定の@Spring_MT、そして私といった感じ。内容についてはまたTDDBC-MLTDDBC Wikiで共有しますので、そちらをご覧下さい。

 

キーノート

そして参加者が集まったところで、TDDBC開始です。すっかりおなじみとなったt_wadaのキーノートセッションです。

t_wadaのキーノートはスライドは何度も読んでいましたが、実際に観るのは初めてでした。もちろんスライドには乗っていないことが実際には多く、これはやはりセッションを観ないとわからないことが多いなと感じました。

メモから起こしてみます。

  • TDDBCのメインは、実はTDDではなく「ペアプロ」
    • ペアプロは楽しい、そして疲れるw
  • コードレビューもポイント
    • 普段の仕事では同じ問題を複数人で同時に解くことはまずない。
    • 他の人、言語のコードと比較することができる。
  • ふりかえりもポイント
    • KPT(Keep、Probrem、Try)でふりかえる
  • ソフトウェア開発の三本柱
    • バージョン管理(一番大事!)
    • テスティング
    • 自動化
  • バージョン管理
    • 人間は忘れる
      • いかに記憶を専用ツールに任せるか
    • メンテナンスと新機能の並行開発
      • VCSなしでは困難
        • セーブなしでRPGをやるようなもの
    • Before DVCS時代
      • CVSの貧弱なマージ機能を補完するため、人間が工夫していた
        • 手でブランチ図を描いて、マージポイントなどを管理していた
        • ただ、開発が進むと管理しきれなくなる
  • テスティング(Test-“ing”)
    • 名詞ではなく進行形
      • 書き”ながら”開発を進める
  • 自動化
    • 人間は
      • 飽きる
      • 疲れる
      • 繰り返しが苦手
      • 創造性がある
    • 機械は人間の逆
      • 飽きない
      • 疲れない
      • 繰り返しが得意
      • 指示したことしかできない
    • 機械と人間でコラボレーション
      • お互いの得意なところで、不得意なところを補完する
      • たとえば
        • コミット:人間
        • ビルド:機械
        • レポート:機械
        • 判断:人間
    • 人間→機械より、機械→人間の通知の割合を大きく
      • 人間は非同期に作業するのが得意
      • Jenkinsなどを活用し、機械の割合を増やす
  • 三本柱以外のメタファー
    • 三種の神器
      • レベルを上げて物理で殴れば、なくても何とかなりそう感あり
      • メタファーとしてはやはりどうかと
    • 三脚椅子
      • 今のところ一番しっくり
      • 先日論破された
        • 「足が一本もなければ安定するじゃん」
        • もっとも
  • テスト
    • コンテキストを合わせる
    • だれが何のために行うか
      • 開発者(TDDはこれ)
      • 顧客(ユーザー)
      • 品証(QA)
  • TDDとは
    • 原典(TDD入門)の書き出しがすべて
      • 「動作するきれいなコードを書き続ける」
  • 2つの道
    • きれいだけど動かないコードから動くコードへ
    • 汚いけど動くコードからきれいなコードへ
  • 動かないコード→動くコードに移るときに「気付き」がある
    • TDDは汚いコードでもまず動くようにする
    • この段階を小さく早く繰り返すことで、「気付き」のタイミングが多い
  • Red→Green→Refactoring
    • 黄金の回転
      • JoJo第7部 Steel Ball Runより
  • 汚いコード→きれいなコード
    • 実現するには「強い意志の力」が必要
    • 「汚さ」に敏感になる
    • 「リーダブルコード」がその助けとなる
    • 汚いコードはいずれ自分が嫌いになる
  • TDDのこころ
    • 一つずつ、少しずつ、段を小さく
      • 問題をBreakDownする
    • 複数を相手にしない、一人ずつ対処する
      • 1対1の連続にする
        • 思ったこと:ただ、疲れはする
      • TODOを先にリストアップ
        • やりやすいところから片付ける
    • 素早く回す
      • 回転が遅い、ということは何か問題がある証拠
    • 自分が最初のユーザー
      • 作る→使ってもらう→フィードバックでは遅いし漏れる
      • 作りやすい<->使いやすいのバランスを見極める
        • トレードオフになるものも多い
        • TDDが導く
    • 不安をテストに
    • 祈るのではだめ
      • テスト、VCS、自動化に守られた状態なら、祈る必要はない
    • 命綱を編む
      • 必要になってから編んでも、もう遅い
      • 日々の習慣に組み込むのがTDD
        • 編んだ命綱を自動化で回す
  • TDDの最大のメリット
    • 心理的なもの
  • TDD=バグ0ではない
    • バグをテストで保護して対処
    • バグのたびに強くなる
  • TDDのテストは目的でなく手段
  • TDDの目的は「健康」
    • コードの健康
    • チームの健康
  • TDD導入事例
    • IBM、MSの論文
      • バグは6割から最大9割削減
      • 実装時間は3から3割増
    • エリクソンの論文(アンケート結果の分析)
      • デバッグ時間の減少
      • コードの品質(外部/内部)の上昇
      • 実装時間は増えるが、トータルコストはむしろ減る
        • デバッグ時間の減少が大きい
  • デバッグ時間現象の意味
    • デバッグ→想定外の作業
    • デバッグを減らす→想定外の時間が減る
    • 計画した時間とのブレが少なくなる

 

TDDのペアプロデモ

キーノートセッション後は、@grimrose、@yattomによるペアプロデモです。FizzBuzzを題材にこんな感じでTDDを進めていました。

  1. TODOリストの作成
    インターフェースの検討もここで行っていました。たとえば、引数、戻り値の型、など。また、例外パターンの考慮も行い、「具体的な例外の型」については後回しにすることも決めていました。
    2以降でも途中で出てきた問題、課題は都度TODOリストに追加して忘れないようにする。
  2. 最初のテスト
    数字を入れたら数字を返すテストを作成し、コンパイルが通るようにしてテストが失敗することを確認するまで行いました。
  3. 仮実装
    テストを通す最短のコードを書くことを「仮実装」といい、「テストコードのテスト」の代わりとなるため、省かずに行ったほうがよい。
  4. 三角測量
    最初のテストに加えてもう一つテストケースを追加し、仮実装から本来あるべき実相を導きます。
  5. リファクタリング
    テストが通ったままの状態を維持しつつ、コードを整理します。
  6. 次のテスト
    Buzzを返すケースのテストなどを書いていきます。
  7. 明白な実装
    Buzzを返すケースができていればFizzを返すケースの実装も明白なので、三角測量はせずに一気に加速して実装してしまう。ただし、最小限のテストは書く。

個人的には、テストコードのリファクタリングのところも見たかったなぁ。

また、デモの途中で次のような質問が出ました。

Q:TDDはどのタイミングでコミットすればよいのか?

A:基本はGreenのタイミングで。ただ、GitなどのDVCSならば、Red、Green、Refactoringのそれぞれでコミットすることもある。ただ、この時もPushはGreenのタイミングで。

 

ペアプロ実習

デモが終わったところで部屋を移動し、ペアプロ実習タイムです。ペアの割合はPHP、Ruby、Javaの3強+他言語(C#含む)といった感じでした。

私は@aetos382と組み、VS2012、C#、MSTest with Chaining Assertionで臨みました。

 

お題

少し前にはやった「LTSV」ライブラリを少し改変したもので、@sue445さんがsue445/tddbc_tokyo_20130316 · GitHubにまとめてくれました。オリジナルのLTSVライブラリとの違いは、setterが変更前の値を返すこと、setした順番で中身をダンプすること、あたりです。

 

ペアプロの様子

まずTODOを2人で洗い出し、例外パターンなどの抜けがないかクロスチェックしました。ちょっとここで全部をやろうとしてしまったことは失敗だったかなと思っています。

そして実装開始です。我々はSet→Get→Dumpと進めていくことにしました。途中Setの値置き換えのテストを、Getを作成する前に行おうとしたところ、Getがないとテストできず、道を誤ったので一度戻り、今度はGetを実装する、といった進め方になりました。

また、最初はDictionary<string, string>をデータストアとしていたのですが、setした順序を保持するといった要件を実現するのに、うまくいかず途中でList<Tuple<string, string>>に切り替えることになってしまいました。

 

結果

LINQを活用したり、Chaining-Assertionを活用したりと、C#らしいコードになったこともあり、最後のコードレビューで採り上げられてしまいました。

 

クロージングセッション

最後にt_wadaによるクロージングセッションで、TDDの応用について話がありました。一言でまとめると、レガシーコード改善ガイドなどの本から他の本、他の本とたどり、スキルを高めていってほしい、といった内容でした。

 

まとめ

私の初めてのTDDBC参加は、こんな感じでした。今回の打合せ結果、イベント参加結果をもとに、5/18(土)に予定しているTDDBC長岡1.0に活かしていくつもりです。

あと、「お題」はまた改めてやり直してGitHubにあげてみようと思います。若干不本意な実装で終わってしまったので。

TDD Boot Camp Tyokyo 2013-03 参加します

TDD Boot Camp Tokyo 2013-03 – TDDBC

 

TDD Boot Camp Tokyo 2013-03

TDD Boot Camp Tokyoを、2013年3月16日に開催します!!!!

開催概要

  • 日時 … 2013-03-16(土曜日)
  • 会場 … 東京都渋谷区神泉町8-16 渋谷ファーストプレイス 8F 株式会社 VOYAGE GROUP 社内バー AJITO
  • 定員 … 30名
  • 参加費 … 2,000円
  • Wi-Fi接続環境 … 会場にて提供できます

参加費用については、今後全国で開催を予定しているTDD Boot Campの運営費として使わせて頂きます。ご協力感謝いたします!

 

結構「TDD!TDD!」言ってる上、5月に長岡で主催しようってのに、実はこれまでTDDBCに参加したことがなかったりします。

んで、「主催するけど参加もしたいなー」というような話をしていたら、@katzchangが開いてくれました!

 

 

というわけで、初出陣。当日は「プログラマが知るべき97のこと」を今更持ち出して、@t_wadaにサインもらおうと思います!

TDDBC長岡1.0:開催日&会場決定

TDDBC長岡1.0の開催日と会場が決まりました。

TDD Boot Camp(TDDBC) – TDDBC長岡1.0

日時

2013年5月18日(土)

時間未定。

会場

まちなかキャンパス長岡 5F交流ルーム

 

当日のタイムスケジュールなどはまだ未定ですが、午前中から夕方までやって、夜は懇親会の予定です。

 

待て、続報!