LoginSignup
5
6

More than 5 years have passed since last update.

@hiralin

TDDBC-Tokyo 20130316

Last updated at Posted at 2013-03-16

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

gihyoの連載

本の話

  • プログラマが知るべき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にして貼ってる
    • 喋ったらはがしてる
5
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
6