TDD Boot Camp 大阪 1.0( #tddbc ) に参加しました
概要
- TDD Boot Camp 大阪 1.0( #tddbc ) : ATND
- なかなかスケジュールの都合がつかず、近場で開催されても参加できないことが多かったので、「次こそは！」と思った矢先の大阪開催だったので参加しました
まとめ
- 楽天カフェテリア＠大阪、非常に素晴らしい会場でした。素晴らしい会場でした！
- カフェテリアは木製の椅子のため、半日近いイベントの場合腰が悪い人は座布団を持って行ったほうがいいですね
- TDDとペアプロに関しての経験をつむことができた
- よしおかさん、関さん、和田さんを独占していたRubyのテーブル…
- その中でも恐れ多くも関さんと和田さんを独占してしまった。会場撮影されていた様子^^; goyo (goyoki) on Via.Me
- 成果物はStep3のはじめまでGitHubにあげました
- よしおかさん、関さん、和田さんを独占していたRubyのテーブル…
- 他の言語でどう書くか、書き方などを見て、自分のメイン言語のテスティングフレームワークでも出来るかな？ と調べる事が大事
- ねんがんのグリーンバンドを手に入れたぞ！
- TDDは一人でも出来るので、どんどん書いて量を質に転化させていく！
- 主催の@Mitsuyuki Shiiba (@bufferings) op Twitter さん、TAの皆さん、スピーカーである@Takuto Wada (@t_wada) op Twitter さん、@Hiro Yoshioka (@hyoshiok) op Twitter さん、@seki at druby.org (@m_seki) op Twitter さん、Ruby島の皆さんお疲れ様でした！
以下、時系列にそったまとめ
TDDのこころ @Takuto Wada (@t_wada) op Twitter さん
BootCampとは
- 新兵に教官が優しく教える
- しかしスライドの画像*1は2012年現在もはや厳しい…
今日やること
- ペアプログラミングを体験してみる
- コードレビュー大会
- 同じコードを同僚と解くという機会はほぼない
- 同じお題を他の人はどう考えるのか、他の言語ではどうなるのか
ふりかえり
- KPT形式でフィードバック
ソフトウェア開発の三本柱
- バージョン管理、テスティング、自動化
- RPGのノーセーブクリア＝バージョン管理なしの開発
- 今コードが動いているのか動いていないのか＝テスティング
- 人間が手作業でやっているものをシェル化、Jenkinsで回したりで機械に任せる＝自働化、自動化
- 機械がうまくいってない時だけ教えてくれる
「テスト」とは
- 誰が、なんのためにテストをするのかで簡単に分類
- Developer Testing
- 開発者が開発促進のため
- Customer Testing
- 顧客が進捗管理のため(受入テストとか)
- QA Testing
- 品質保証担当者が品質保証のため
- Developer Testing
「TDD」とは
TDDのサイクル
- テストを書き
- テストを実行して失敗させ(Red)
- 目的のコードを書き
- テストを成功させ(Green)
- そのテスト通るまま中を綺麗にしていく(Refactor)
- これを繰り返す
TDDのやり方
- 大きな問題は切り分けて1つずつ
- たくさんの問題も1つずつ
- 何をテストすればよいのか
- 開発を進めにくくする要因→何かわからないもの、不安
TDDをすることにより
- 即座にフィードバックを得る
- 書いたコードへの自信持つ
- これから書くコードに自信を持つ
TDDの真の目的
- 不安の克服
- 健康
- コードの健康=仕様変更に対応できる
- チームの健康=仕様変更に備える事ができる
ペアプロ
- Ruby島は4人でした
- お題はこれ。結構複雑 TDD Boot Camp(TDDBC) - TDDBC大阪1.0
- テーブルにバリバリ使ってるぜ！ という人がいなかったのでどう組もうかー相談していたら、なんとよしおかさんと関さんが「Ruby席に混ぜて」という状況に
- 恐れ多くも関さんとペアプロさせて頂く事態に((((;゜Д゜)))
- RSpecでどうテスト書こうかというところで、どういう単位でテストを作るかのような話になり、色んな書き方があるのだなと感じました。
- 僕は「小さい自前のスクリプトに対してのテスト」くらいの使い方しかしていなかったから一個一個の振る舞いに対して1つずつit "〜できる、it "〜する"と実装していこうと考えていた
- 対して、関さんは一つのテストをシナリオで考えていたので、はじめにこうしてこうやって最後にこうという感じ
昼休み
- 楽天デリバリによるお弁当サービス
- 結構種類が豊富だった
昼休み2 実際の事例(和田さんの午前セッションの続き)
- TDDを採用したときのTDDを採用していない類似プロジェクトと比較
- 例えばIBM、15%~20%くらいテストコードのための実装時間が増えたが、4割くらい欠陥が減った
- Visual Studioがすごい！欠陥密度0.09
- テストコードを書く時間は増えるが、軽微なミスが減るため、デバッグの工数は減る→トータルで開発工数を減らす事ができると考えられる
昼休み3 LT
午後の部開始 QA
- テストメソッドの名前はどうやって考えているか
- 日本語で書いている、英語の場合はxx is … when …
- テスト名のテストの中身が重複していたらDRY的にはどう？
- RSpecの場合構造だけでテストの意味がわかるようにしている
- 入れ子構造で意味がわかるようにするのが最近のテストのトレンド
- 状況は詳しく書くけど何をの部分はサッパリと書く
- enclosed
- プライベートメソッドのテストをしたい…
- プライベートメソッドはパブリックメソッド経由でテストできるはずなので、プライベートメソッドをテストしたいといっている時点で設計がおかしい
開発者の皆さん、テストを書こう よしおかさん
事例 Oracle8の開発現場
事例2 DEC Rdb
- 米国で開発されたソフトウェアを日本語へ
- ソフトウェア国際化のあるべき姿の議論
ペアプロ午後の部
- 後ほど発表があるということで関さん離脱。ありがとうございました
- なんとバトンタッチは和田さん((((;゜Д゜)))
- 和田さんが午前中に書いていたテストをガンガン洗練させていく！
- 黄金の回転で一番難しいと思っているRefactorの部分を間近で見ているのでマジでためになる！
- 今回教えて頂いたのはitの中は簡潔になるように心がけるというもの
- テストのための準備をbeforeで書く！
- contextでは「この時、これを確認、これを確認」レベルで済ませるように書く。
- contextの中身はlet, its, itsで！
- という事らしい。確かに見やすい
- これで、他の状態の時にこうあるべきというのも一行追加でいける
describe "投入金額に注目" do before do @vending = Vending.new @change = @vending.enter(input) end subject { @vending } context "だめな硬貨だけのとき" do let(:input) { [1,5,2000] } it { @change.should == [1,5,2000] } its(:show) { should == 0 } end context "1000円札を入れたとき" do let(:input) { [1000] } it { @change.should == [] } + its(:show) { should == 1000 } ＃この状態の時にも end
TDDとは 関さん@seki at druby.org (@m_seki) op Twitter
TDDのおさらい
- 今日楽しかった？
TDDのサイクル
- 次の目標を考える
- その目標を示す
- 黄金の回転…
- これを繰り返す
TDDはなんだっけ
- テストによって導かれた開発の事
- 今日のは実装例の一つかも
TDDの変形
もうひとつのテスト
- Checking
- 既知の情報の確認
- Testing
- 新しい情報、未知の情報を探す
ご提案
- Red Green Refactor
- ちょっとずつ仮設の上に仮設を重ねる
- Destroy
- この実装ならバグが出るだろみたいなのを
- たまに破壊的な思考を持ち込む
QA
終わりに 和田さん
- ペアプログラミングをやってテストのサイクルを回す
- コードレビュー大会
- 「あの言語でこんな事出来るんだ」発見→「俺の言語でもできんじゃん！」
- 黄金の回転
- 各象限を越えるときの心持ち
- 本をたどる
- 2人目がいないので広めるのに心が折れちゃう
- まず一人でやって見せて背中を見せる
- 量は質に転化する
そして懇親会へ…
- ピザが一瞬でとけた
