TDD Boot Camp 東京 1.6へ参加した際のメモです.
- 日時 :2011.07.31 10:00-18:00
- 場所 :ニフティ株式会社 セミナールーム
- 参加者数:30名前後
- 参照 :http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GPGlAww
今まで,なにかとTDDは話に聞いていて,興味を持っていたのですが,
私自身が楽に書ける言語がC言語位で参加できずにいました.
しかし,今回はC言語でもTDD Boot Campに参加可能となったので,参加してきました.
C言語チームおよびTAの@tosikawaさん,主催者の方々,講師の和田さんありがとうございました.
■全体感想
- 講演を聴いたすぐ後に体験で腑に落とすのは良い.
- 他言語の話を聞くのは別の観点が生まれて興味深い
- ただし,時間は足りなくなりやすい.
- 多言語で同じお題とするのは,言語標準ライブラリなどのサポート差によって,大変さが異なる.
- お題をこなすことが目標ではないので,大きな問題ではないが.
■和田さん講演
- TDDBCは教わるだけでなく,体験して欲しい
- ペアプロが自分にどんな効果をもたらすか感じて欲しい
- 11/5横浜
- ソフトウェア開発の三本柱
- バージョン管理
- テスティング
- 自動化
- 最も大切なモノはバージョン管理
- バージョン管理
- ソフトの歴史を管理する
- 自動化
- 大事なことは機械ができることと人間ができることを分けて考え,機械ができることは機械にやらせる.
- すこしずつでいいから機械ができることを増やしていく.
- すすむと,だめなときだけ機械が人に働きかける.自働化.
- 大事なことは機械ができることと人間ができることを分けて考え,機械ができることは機械にやらせる.
- 三本柱というより,三脚
- 一本でもかけるとたちゆかない
- テストという言葉は範囲が曖昧.
- 開発者テストを追求していったものがTDD
- TDDの心持ち
- 1つずつ,少しずつ
- 分割するのはスキル.練習が必要.
- ひとりずつ仕留める
- 1対多ではなく,1対1の連続にする
- すばやくまわす
- 自分が最初のユーザ
- 使いやすさなどがわかる
- ドッグフード
- 使い手になることで,動けばいいじゃんから脱する
- 道具にこだわる
- ツールの改造や調べていくことを貪欲に.
- 不安をテストに
- 品証や顧客用のテストはテスト技法からつくっていく
- TDDのどこの,どこまでテストを書くか,に対しての解
- TDDのテストは開発者の不安を解決ためにおこなう.
- 祈るのでは駄目だ
- テストが命綱
- 命綱は常に編みこんでおかないとダメ
- 1つずつ,少しずつ
- なぜTDDをするのか
- 完璧ではないから
- すばやくフィードバックを得たい
- TDDは目的ではなく手段
- 最大のメリットは心理的側面
- 即時にフィードバックを得るため
- 書いたコードに自信を持つため
- これから書くコードに自信を持つため
- 最大のメリットは心理的側面
- TDDの目的
- 健康
- コード
- ムダのない,引き締まったコード
- 変化に対応しやすくなる
- チーム
- コード
- 健康
- TDDは個人スキルなので,自分だけで始めることができる
■事例
- 調査論文がいくつかでている
- ざっくりというときは,「バグは半分,実装時間は2割増」
- エリクソンの事例の開発者アンケート
■デモ
- TDDの主眼
- ペアプロの感じを見て欲しい
- FizzBuzz問題を例に.
- ゴールから書いていく
- 利用者の視点
- ゴールから書いていくのでコンパイルエラーはほおっておく.
- テストコードの中にメソッドをつくってしまっても良い.
- t-wadaさんは,育ってきたら,それをプロダクトコードへ移すやり方をしている.
- 仮実装:fake it
- グリーンにする最小のサイクル
- 複雑な問題なときほど,仮実装の価値はある.
- テストのバグが明確になる.
- テストコードのバグをチェックする
- テストコードとプロダクトコードは交互にチェックする
- 仮実装の段階では,テストコードのリファクタリングなどが考えられる.
- triangulation:三角測量
- 仮実装を再び設計のラインに載せ直す
- バージョン管理
- 中央型と分散型で異なる
- 基本はレッドの状態でコミットしない
- グリーンのタイミングでコミットする
- ただし,分散型の場合,手元は開発者のものなので,好きなときにコミット
- テスト書いたらコミット,コード書いたらコミットなど.
- 最小サイクルの2択: 仮実装と三角測量 or 明白な実装
- 仮実装と三角測量でTDDをまわすのが小さいサイクル
- 不安が大きい場合
- テスト書いてすぐ実装する場合もある
- 明白な実装
- 不安が小さい場合
- 仮実装と三角測量でTDDをまわすのが小さいサイクル
■演習時のメモ(13:30-15:00,レビュー&休憩,15:30-17:00,レビュー&休憩)
- C言語チームは4人.2人と2人の2チームを構成.
- さすが,C言語チーム.4人中3人が組込系のお仕事.
- 使用テスティングフレームワークは,PCUnit
- PCUnit:https://github.com/katono/PCUnit
- @mayonezudaiouさんが紹介してくださった
- TAは@tosikawaさん,近くに@goyokiさん
- C言語チームは環境自体をどうするかから議論開始
- 第1ペア:@mayonezudaiouさん
- 間違って実装を先に行ってしまった場合には,テストまでつくって,実装をバックさせてテスト実行させる.その後実装を戻し,グリーンになるか確認する.
- CUnit/CPPUnitだとメッセージだせる
- 第2ペア:@twilight_breezeさん
- CUnitだとオプションで,メモリ解放していないものを表示することができる.
- 不安が一杯出てきたときは,とりあえず全部メモするなり,テストコードにしておくなりして,だしておく.
- ただし,やるかどうかは別.
- テスト書いても,テスト登録すること忘れがち
- テスティングフレームワークとして,Cutterを使ってもみたかった.
■bleisさんのF#(MSのMVP)実装
- ナチュラルスペック
■和田さんの応用についての話
- テストコードのないコードがいっぱい
- レガシーコード改善ガイド
- コードのないコードに対,してどうしたらいいかが書かれている
- レガシーコード改善ガイド
- 既にデータの入ったデータベースがある
- データベースリファクタリング
- テストが脆い
- 仕様が変わるたびに,コードを変更しなければならないテストを,脆いテストと呼ぶ
- テストが遅い
- xUnit Test Pattern
- 元ネタはwikiにある.本のほうが詳しいが.
- Growing Object-Oriented software guided by tests
- モックの概念を作った人たち
- #goos_jp
- プロとしてテストコードを書く嗜み