TDDBC-Tokyo 20130316

## 和田(t-wada)さんセッション

### gihyoの連載

+ http://gihyo.jp.dev/serial/01/tdd
+ 動画つき
  + ニコニコ動画でも見れる

### 本の話

+ プログラマが知るべき97のこと
+ SQLアンチパターン

### Boot Camp

+ 新兵を鍛え上げる
+ オフィシャルでは今回で31回目
+ ペアプログラミング経験、TDD経験を体験してもらうこと
  + 衝撃的な体験になるはず
  + ペアプロは楽しい！
  + ペアプロは疲れる！

### コードレビュー大会

+ 普通の会社でやるレビューとの違い = みんなが同じお題をやる
+ 自分達が考えたお題をみんながどうかんがえたかが分かる

### 最後

+ ふりかえり
  + よかったこと
  + わるかったこと

## 本題

+ バージョン管理
  + ソフトウェア開発は、案外スパンが長い
  + 人間の記憶力はショボい
  + 昔はCVSで、ブランチの管理が苦手だった
    + 人間の手でブランチの管理してた
  + 機械に任せましょう
  + バージョン管理/テスティング/自動化でどれが一番大事かといえば、バージョン管理

+ テスティング
+ 自動化
  + "自働化"
    + 人間の手 -> 機械から、機械 -> 人間への制御の向きを逆転
      + 人間は機械とは非同期にどんどんコミット
      + 機械が自動的にテストして、何かあったら人間に教えてくれる仕組みをくみ上げる
+ 例え
  + 三種の神器、とこれまでは呼ばれている
    + 大事さの表現として足りていない
  + 最近三脚椅子
    + 1本足でも2本足でも安定しないどころか、役目を果たせない
      + 最近論破された -> 3本とも無ければ安定する

### 「テスト」にまつわる混乱

+ テスト、という言葉は文脈や組織によって全く意味が異なる
  + 訳し方が難しい

### 「テスト」の考えかたの一つのモデル

+ 「誰が、何のために」
+ Developer Testing
  + 開発者が、開発促進をするために
+ Customer Testing
  + 顧客(のロール)が、進捗管理をするために
  + 受け入れテストと呼ばれる
+ QA Testing
  + 品質保証の担当者が、品質保証をするために

### Developer Testingとは(今日の話)

+ プログラマの
+ プログラマによる
+ プログラマのための
+ プログラムとしてのテストを書きながら
+ 開発を行っていく手法

### TDDとは？

+ テスト駆動開発入門
  + Kent Beck
  + だいたいこの本に全部書いてある
  + 何度読んでもいい
  + 書き出しが、すべてを表現している
  + 「動作するきれいなコード」
    + あらゆる理由で価値がある

### 動作する、きれいなコード

+ 綺麗な設計 -> 「動作する綺麗なコード」
  + 完璧な設計は定義ができない
  + 設計は完璧になったが、一行もコード書いてないのにスケジュールがギリギリなんてことに
  + コードを書く時には、どうせいろいろな事に気付く
+ TDDのサイクル(これが全て)
  + 次の目標を考える
  + その目標を示すテストを書く
  + テストを実行して失敗させる(Red)
  + 目的のコードを書く
  + 最短のコーディングで、書いたテストを成功させる(Green)
  + テストが通るままでリファクタリングを行う(Refactor)
  + これを繰り返す
+ 上記が、黄金の回転
  + スティールボールランをよめ

+ 古い言い伝え
  + 「動いてるコードをいじるな」
  + 動いてい

+ 汚いコードに敏感になることはすごくだいじ
  + リファクタリング
    + Ruby版もある
  + リーダブルコード
    + 超いい本だからよめ

### テスト駆動開発の大事なポイント

+ 粒の細かさ
  + 一つずつ少しずつ
  + 段を小さく
  + 宮本武蔵
    + 複数を相手にしない
    + 一人ずつ相手にする
+ すばやくまわす
  + ペアプロの相手もすばやく回す
  + 素早く回ってないのは、何か問題がある

+ 自分が最初のユーザ
  + 実装より先にテストを書く
  + 自分が書いたコードは、必ず自分が最初のユーザになる
    + 日々の開発だと、自分が最初のユーザになることはあまりない
    + よかれと思って書いたコードが、他人には使いづらかったりする
  + 「作る前に使う」
    + すでに作ったコードが存在しないから、未練がない
  + 使いやすいコードと作りやすいコードは違う
    + 使いやすいコードはちょっと作るのが大変だったりする
    + 作りやすいコードを先に作っていると、捨てるのが勿体ないと思ってしまう

+ 「不安をテストに」
  + TDDには、どこまでテストをするか、という定量的な基準はない
  + 開発が止まるときというのはどういうときか = 不安があるとき
  + 不安があるところをテストにしよう
    + ヘンな基準があると、getterやsetterにもテストを書かされたりする
      + プログラマとしては、こんなところに不安はない
      + 逆に複雑なメソッドには多くのテストを書いて不安をなくしたい
  + 祈るのではダメ
    + 不安は消えない
  + 「命綱を編む」
    + でかいシステムは、バンジージャンプみたいなもん
    + 命綱は一朝一夕で作れるもんではない
    + 少しずつ命綱を編んでおくべき

### まとめ

+ 最大の理由は、ソフトウェア的なメリットではなく、心理的なもの
  + 即座にフィードバックを得られる
  + 書いたコードに自信を持つため
  + これから書くコードに自信を持つため
+ テストは目的ではなく、不安を取り除く手段
+ TDDの真の目的
  + 「健康」
  + 変化に対応できるのは、健康体のコード
    + 無駄なく、むら無く
    + 良い構造を持っている
  + 変化に対応できるのは、健康体のチーム
    + テストは毎日毎日jenkinsが回してくれてて、何かあったら教えてくれる
+ 「不安の克服」「健康の維持」

### 事例

+ TDD導入効果について
  + MS/IBMの統計
    + 類似プロジェクトとの比較で、欠陥40%〜91%減
    + 実装時間15%〜35%増加
  + 「不安の克服」が主目的なので、これはあくまで副次的効果

+ ざっくりとした説明
  + 「実装時間が2割増えて、バグが6〜7割減ります」

  + エリクソン他
    + 被験者を対象としたアンケート
      + 96%の被験者がデバッグの工数を減らすと感じた
      + 88%の被験者が、要求が洗練されると感じた
      + 92% の被験者がコードの品質を上げると感じた
      + 50%の被験者が開発工数を減らすと感じた
        + おかしい、実装時間増えてるはずなのに、工数は減ったと感じられている
        + 答えは上記で出ている。実装の工数は増えるが、「96%の被験者がデバッグの工数を減らすと感じた」
    + TDDを実施した場合に報告されている知見
      + 機能テストでの不具合検出数が18%削減された
      + コーディングの時間が16%増えた
      + テストのカバレッジが大きくなった

### ペアプロのデモ

+ FizzBuzz

  + 設計としてTODOリストをかいていく

+ ペアプロのプロトコル
  + あいさつしましょう
  + ゴールとやることを決めましょう
  + TODOリスト
    + 数字をそのまま文字列で返す
      + (System.outだとテストがしづらいですよね、表示する、ではなく返す、にしましょう)
    + 3の倍数だと"Fizz"を返す
    + 5の倍数だと"Buzz"を返す
    + 3と5の倍数だと"FizzBuzz"を返す
    + (これ以外のパターンはあるか？)
    + (0の場合どうします？)
    + 「1以上の整数」以外なら例外(IlligalArgumentException)を返す
    + (他に懸念事項ありますか？)
    + (まずは、これで大丈夫だと思います)
    + (どういったクラス名にしましょうか？)
    + (FizzBuzzにしましょう)
    + (ではテストはFizzBuzzTestにしましょう)
    + (テストを作成し、失敗を確認)
    + (失敗しましたね)
    + (テストメソッド名はどうしますか？私は日本語が好きです)
    + (ではこうしましょう。 public void 数字をそのまま返す(){})

    + (質問) : バージョン管理システムへのコミットは、どのタイミングでやるべきですか？
      + (t-wadaさん) : テストがグリーンになった時です
      + gitだと、コミットとプッシュが分けられるから、テスト書いてコミット、Redでコミット、リファクタリングしてコミット、Greenでプッシュ、なんかもできる
      + SVNだと、怪しい
+ 三角測量
  + テストが間違ってたらどうするんですか？
    + テストのテスト、そのテストのテストのテスト、とやっていくときりがない。
    + テストと、実装コードが互いにテストしあう関係を目指す

+ 明白な実装
  + 不安の量が小さいテスト、実装は一気にテストと実装に逝く(トップギアのモード)
  + 三角測量を使うのは不安が大きいケース。テストを失敗させ、Red->Green->Refactorのループをする

+ Java
  + @TODO/@Think/@FixMeなんかのアノテーションで忘れないようにできる

### その他

+ 司会のkatchangさん
  + ポストイットのでかいやつに喋ることをTODOにして貼ってる
  + 喋ったらはがしてる