TDD Boot Camp 大阪 1.0( #tddbc ) に参加しました

目次

[TDD][RSpec][Ruby][イベント]TDD Boot Camp 大阪 1.0( #tddbc ) に参加しました

概要

  • http://atnd.org/events/28762:title
  • なかなかスケジュールの都合がつかず、近場で開催されても参加できないことが多かったので、「次こそは！」と思った矢先の大阪開催だったので参加しました

まとめ

以下、時系列にそったまとめ

TDDのこころ @[https://twitter.com//t_wada:title] さん

BootCampとは

  • 新兵に教官が優しく教える
  • しかしスライドの画像[1]は2012年現在もはや厳しい…

今日やること

  • ペアプログラミングを体験してみる
  • コードレビュー大会
    • 同じコードを同僚と解くという機会はほぼない
    • 同じお題を他の人はどう考えるのか、他の言語ではどうなるのか

ふりかえり

  • KPT形式でフィードバック

ソフトウェア開発の三本柱

  • バージョン管理、テスティング、自動化
    • RPGのノーセーブクリア＝バージョン管理なしの開発
    • 今コードが動いているのか動いていないのか＝テスティング
    • 人間が手作業でやっているものをシェル化、Jenkinsで回したりで機械に任せる＝自働化、自動化
      • 機械がうまくいってない時だけ教えてくれる

「テスト」とは

  • 誰が、なんのためにテストをするのかで簡単に分類
    • Developer Testing
      • 開発者が開発促進のため
    • Customer Testing
      • 顧客が進捗管理のため(受入テストとか)
    • QA Testing
      • 品質保証担当者が品質保証のため

「TDD」とは

  • テスト駆動開発入門 ケント・ベック
  • 動く、きれいなコードへ
    • そこに至るための道へは？
      • きれいな設計をして、それを実装して、それが動作する…きれいな設計とは？
  • 動かすことで初めてわかることがソフトウェア開発にはとても多い
    • なら早く超えよう(ただしここで止まると技術的負債になる)

TDDのサイクル

  • テストを書き
  • テストを実行して失敗させ(Red)
  • 目的のコードを書き
  • テストを成功させ(Green)
  • そのテスト通るまま中を綺麗にしていく(Refactor)
  • これを繰り返す

TDDのやり方

  • 大きな問題は切り分けて1つずつ
  • たくさんの問題も1つずつ
  • 何をテストすればよいのか
    • 開発を進めにくくする要因→何かわからないもの、不安

TDDをすることにより

  • 即座にフィードバックを得る
  • 書いたコードへの自信持つ
  • これから書くコードに自信を持つ

TDDの真の目的

  • 不安の克服
  • 健康
    • コードの健康=仕様変更に対応できる
    • チームの健康=仕様変更に備える事ができる

ペアプロ デモ(FizzBuzz)

  • ゴールから書く！
    • Fizzの場合
      • 何がゴール？
      • Fizzが返る
      • どうなった時Fizz？
      • …としていく
  • テストコードのテストってどうするの？
    • テストコードと実装コードを互いにテストしあう！
      • そのタイミングは実装する前にやってしまう、仮実装してしまう
  • 実際にペアプロのデモを第三者視点で見て、以下のようなことを思った
    • 文化の違いをどう解決していくか
      • エディタ、キーバインド、などなど
    • 細かなTipsが共有されていく
      • 「xxはyyっていうショートカットで出せますよ」「知らんかった…」
    • ナビゲータって一人で仕事をしているときはやる事がないので結構難しそう…

ペアプロ

  • Ruby島は4人でした
  • お題はこれ。結構複雑 http://devtesting.jp/tddbc/?TDDBC%E5%A4%A7%E9%98%AA:title
  • テーブルにバリバリ使ってるぜ！　という人がいなかったのでどう組もうかー相談していたら、なんとよしおかさんと関さんが「Ruby席に混ぜて」という状況に
    • 恐れ多くも関さんとペアプロさせて頂く事態に[2])
  • 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の開発現場

  • 95年~2000年
  • Sun Workstation～
  • ファイルの仮想化、一人で複数のブランチを持てる
  • 開発プロセス
    • 開発者は要求を自分で定義する
      • リファレンスマニュアルのベース
    • 設計する
    • 実装する
    • デイリービルド、リグレッションテスト
    • 安定化プロセス
    • コードフリーズ(重大なバグ以外変更しない)
  • プログラマ
    • 設計者が実装者でテスタ
      • 一つの機能に関して世界で一番知ってる
  • デイリービルド
  • リグレッションテスト
  • 安定化プロセス
    • バグ修正だけ
    • バグや不具合はリリースノートに
  • 学んだこと
    • デイリービルドによって常に動作が確認できる

事例2 DEC Rdb

  • 米国で開発されたソフトウェアを日本語へ
  • ソフトウェア国際化のあるべき姿の議論

事例3 日本語COBOL

  • チェックインの数やバグの数、修正済みバグの数を手書きで書いていた
  • 新人(よしおかさん)のしつけ
    • 「プログラム書きました」「チェックインした？」「あ、してません」「」など
  • デバッグの仕方、質問の仕方も教わった

Samba3.0国際対応

  • 2.xから3.0での日本語の問題
  • テストをどんどん作ってバグを登録しまくり、コミュニティに入り込んでいった
  • 小さいパッチをちょこちょこと
  • OSSでもテストファーストで出来た

ペアプロ午後の部

  • 後ほど発表があるということで関さん離脱。ありがとうございました
    • なんとバトンタッチは和田さん[3])
  • 和田さんが午前中に書いていたテストをガンガン洗練させていく！
    • 黄金の回転で一番難しいと思っている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

レビュー

  • C++, C#, Groovyのチーム
    • 他の言語でこうやってますとあったものがRSpecで出来るか

TDDとは 関さん@[https://twitter.com//m_seki:title]

  • XP10年
  • The dRuby Book
  • Legendary Japanese Ruby hacker

TDDのおさらい

  • 今日楽しかった？

TDDのサイクル

  • 次の目標を考える
  • その目標を示す
  • 黄金の回転…
    • これを繰り返す

TDDはなんだっけ

  • テストによって導かれた開発の事
  • 今日のは実装例の一つかも

TDDの変形

  • 何かを引く
    • xUnitを引いてみる、どうなるか
      • すぐに準備出来ない複雑なUIなど
    • 顧客テストをxUnitなしで
      • JaSST’04
      • 毎日増えるテストを毎日飛び越える(忍者の修行)
  • 何かをたす

もうひとつのテスト

  • Checking
    • 既知の情報の確認
  • Testing
    • 新しい情報、未知の情報を探す

ご提案

  • Red Green Refactor
    • ちょっとずつ仮設の上に仮設を重ねる
  • Destroy
    • この実装ならバグが出るだろみたいなのを
    • たまに破壊的な思考を持ち込む

QA

  • assertなんとかの効率的な探し方
    • Javadoc見れ
  • レガシーコードに対するTDD
    • レガシーコード改善ガイドおすすめ
    • 外側から攻める。Sambaの時はそうやった(よしおかさん)
  • 荒い粒度のテストとは
    • 画面に近いところ、とか入出力とか
    • 単体テストやりにくいテスト(レガシーコード)にたいしてやりやすい表面から攻めていく
  • テストの期待値を作るのに困ったこと
    • input, outputのリストを書く
    • ソフトウェアテスト技法ドリル読む
  • TDDの文化がないところでどう根付かせるか
    • 毎日テストが僕らを守ってくれると提唱した
    • まずは自分から、自信をつけてから広めよう

KPT

  • 会場よかった
  • 会場盛り上がってた
  • TDD体験できてよかった
  • ペアプロも体験できてよかった
  • TAがたくさんいて聞きやすかった
  • Groovy
  • 知らない言語のテストコード、フレームワークを見れてよかった
  • 社内に広める自信がついた＞Groovy？
  • Groovy楽しかった
  • Vimに詳しくなった
  • Groovyいいよ
    • などなど

Groovy人気がすごい。

終わりに 和田さん

  • ペアプログラミングをやってテストのサイクルを回す
  • コードレビュー大会
    • 「あの言語でこんな事出来るんだ」発見→「俺の言語でもできんじゃん！」
  • 黄金の回転
    • 各象限を越えるときの心持ち
  • 本をたどる
  • 2人目がいないので広めるのに心が折れちゃう
    • まず一人でやって見せて背中を見せる
  • 量は質に転化する

そして懇親会へ…

  • ピザが一瞬でとけた

[1] ビリーズブートキャンプ

[2] ((;゜Д゜

[3] ((;゜Д゜

関連記事(この記事の初版より古い記事はリンクがグレーで表示されます)

  1. 2012/05/28 [Ruby] [イベント] [Jenkins] [Redmine] Jenkins,Redmine使いこなし勉強会に参加しました と、ちょっとプラグイン作ってみた #jen_red
  2. 2014/08/28 [Sphinx] [Ruby] [イベント] kawasaki.rb #015 でSphinx導入事例の発表をしてきました #kwskrb #sphinxjp
  3. 2014/07/13 [Sphinx] [Ruby] [イベント] kawasaki.rb #013 でSphinx導入事例の発表をしてきました と #011 #012 参加記録 #kwskrb #sphinxjp
  4. 2014/04/01 [Ruby] [Jekyll] [イベント] kawasaki.rb #010 で発表してきました #kwskrb
  5. 2013/04/27 [Ruby] [Chef] [イベント] BPStudy#68に参加しました #bpstudy
  6. 2012/12/25 [Ruby] メモ化を知った
  7. 2012/11/12 [Ruby] [Jekyll] はてなダイアリーのエントリをJekyllへ移行する
  8. 2012/10/10 [Jekyll] [Liquid] [Ruby] Jekyll(Liquid)で記事の目次を出力するプラグインを作ってみた
  9. 2012/10/01 [Ruby] [Bundle] [Windows] bundle execを省略したいのでバッチを作った(Windows版)
  10. 2012/09/21 [Python] [Ruby] [Jekyll] Pygmentsを使ってJekyll内記事のコードハイライトを実現する
  11. 2012/09/20 [Jekyll] [StartUp] [Ruby] JekyllをGitHub Pagesに上げるための準備
  12. 2012/09/14 [Ruby] [StartUp] [Jekyll] JekyllとJekyll Bootstrapでかんたん静的サイト生成…するための準備
  13. 2012/09/13 [Ruby] [Fluentd] Fluentdの自作プラグインがロードできないのでソースの中身を追ってみる…
  14. 2012/08/17 [Fluentd] [Ruby] Fluentdのプラグインを作成してみる(練習用)
  15. 2012/07/17 [Ruby] [Windows] [Redmine] Windows版Redmineをサービスに登録してブート時に起動させる(宿題あり)