TDDBC横浜 t_wada基調講演メモ

TDD

バージョン管理

テスティング

    • 安心の土台
    • 自分が書いたコードをすぐに試す

自動化

    • 合理化
    • 浮いた時間をコミュニケーション、設計に
    • genkins
    • 自動化を一歩進める → マシンからの通知 おかしい時だけ知らせる

上の3つを三脚椅子に例える。 → 3つ揃わないと確実に倒れる。

テストという言葉の定義

    • 言葉の示すものがバラバラ
    • 会社ごと、組織ごとに意味するところが違う。
    • 粒度とか範囲、フェーズで捉えると限界がある。
    • テストの再分類
      • 誰が何のためにテストを行うのか
      • 開発者
        • 開発促進
        • 自信をもって開発するために
      • 顧客(プロダクトオーナー)
      • 品質担当
        • 品質保証
        • パフォーマンスやセキュリティ等
        • QAテスト

TDDとは

    • 目的
      • 動作する、きれいなコード
      • 4象限
      • ソフトウェア工学から見て、このゴールに到達するには、
        • 到達するには、動作させてから綺麗にするか、綺麗に書いてから動くようにするか。
    • 昔は完璧な設計があると思っていた。それが無いとコードを書いてはいけないという意識があった。
    • しかし、実際にコードを書いたらそうじゃなかった。
    • 完璧主義の呪い。← 設計に捉われつづける。
    • コードを人に見せることへのハードル。
    • テスト駆動開発は、動作するコードを書いてからきれいにすることを教えてくれた。
    • 開発において気付きが得られるタイミングは、動作する壁を越えた時。
      • 動くけど汚いコードを綺麗にするには意思が必要。
      • リファクタリングへの線を越えやすくする。
      • そして細かく綺麗にする。
      • ボーイ・スカウト理論
        • キャンプに来た時は、来た時より綺麗にして帰る。
        • プログラミングに応用する。チェックアウトしたら、次にチェックインする時には必ずどこか1つでも綺麗にする。

TDDのこころ

    • 一つづつ、少しづつ
      • テスト書く、コミット、コード書く、コミット、リファクタリング
      • ToDoリストの粒度
      • タスクを小さく割るというのはスキルであり、訓練により鍛えられるもの
    • 一人づつ仕留める
      • 宮本武蔵
        • 1:nの戦いにどうやって対処するか。
        • 1:1に分解する。
      • 一番肝心なものから仕留めるとか、一番簡単なものから仕留める。
      • 考えておくのは一つに絞る。
    • 素早く回す
      • テンポが大事。
      • サイクルを素早く回す。
      • 実行結果も可能な限り早く。
        • 第一歩が小さい方がやりやすい
      • (テストを書き初めるまでの時間は？)
    • 自分が最初のユーザーに
      • 先にテストコードを書く。自分が書いたコードの最初の利用者は自分になる。
        • コードを書く人と使う人が分かれていることが良くある。
        • そうすると、使いやすいかどうかを書く人が認識できない。
        • 自分で利用するコードを書くことで、Why, Whatに気付くことが出来る。
        • 作成者の脳から利用者の脳へ
        • (テストしやすいコード ニアリー 使いやすいこーど？)
    • 道具にこだわる
      • コードを書くこと、テストと実装の切り替え、結果を早く表示するには。
      • TDDに限らない。開発者として大事なこと。
    • 不安をテストにする
      • テストをどこまで書けばいいのか？
      • 不安を克服できるように書く。
      • 自分の手が止まる時はいつ。
        • テストを書いて試す。
      • 自分が分からないものは何かを見出す。
    • 祈るのはダメ
      • テストが無いから、祈りながらデプロイ押すのは辛い。
      • やってみるまで分からない、なんてのはダメ。
    • テストは命綱
      • 外部要因の変化に対応する。
      • 事前に用意しているからこそ、急な要求に対応できる。
      • ただし、義務感からではない。自分が安心できる状態をキープしたいと思っているからできること。
    • なぜTDDをするか
      • 自分は完璧ではない。
      • 素早く近づきながら、フィードバックを得て陣地を広げキープし続けるために。
    • テストは目的ではなく手段
      • 即座にフィードバックを得る
      • 書いたコードに自信を持つ
      • これから書くコードに自信を持つ。
      • TDDを実施する人が増えているのは、心理的な効果によるところが大きい。
    • TDDの真の目的
      • それは健康
      • 変化に対応するには
        • 健康体なコード
    • 変更に対する影響範囲が分かる状態
        • 健康体なチーム
    • 気持ちに余裕が必要

事例

    • TDDの導入効果(MS,IBM)
      • TDDを採用しなかった場合、した場合の欠陥密度を比較する。
        • 欠陥密度はかなり減少、一方でコード実装時間は増加する傾向。
      • 偉い人に説明する際の、TDDのざっくりした言説に近い結果。
        • 実装時間は2割増えて、バグが6割減る。
    • TDDの導入効果(エリクソン)
      • 被験者を対象としたアンケート
        • デバッグの工数を減らす
        • 要求が洗練される
        • コードの品質を上げる
        • 50%の被験者が開発工数を減らすと感じた。
    • 実装時間は増えるのに？ → デバッグが減るから。和田さんも同様に感じた。
    • 小さいバグはかなり消せる。テストコードがあることで絞りこみが楽になる。
    • デバッグは、仮説検証なので、工数が読めない。

応用

    • テストの無いコードが沢山ある。
    • レガシーコード改善ガイド
      • 帯のアオリを考えたのは主催者のせとさん。
      • 現場のカオスに立ち向かうために役に立つ本。
    • 既にデータの入ったデータベースがある。サービス稼動中。
    • データベースリファクタリング
      • コードより変更がシビア
    • テストが脆い
      • ベースのフレームワークの変更、業務ドメインを追加、データ構造の変更。
      • 一気にテストが落ちる。
      • 実装に対するテストをしすぎている。
        • モックの利用により、実装側に寄りすぎてしまうなど。
      • 内部の実装に対するテストを改善したい時にテストが邪魔をすることになる。
      • メンテナンスしやすいテストを考える。
    • テストが遅い
      • 最長のテスト実行時間は3日間。
      • テストの遅さが、TDDサイクルの遅さになる。
      • xUnit test Patterns (凄い分厚い、900ページ)
      • Growing Object-Oriented Software, Guide by Tests
        • モックの概念を作った人が書いた本
        • 次のTDDのバイブルになると思っている。
        • #goos_jp 読書会実施中。

この先生きのこるために

    • たくさん本を読む
    • それぞれの書籍が示しているものは相互に繋がっている。
    • テスト、TDDはスキルであり、訓練により鍛えられる。
    • むしろ完璧じゃない凡人のためのもの。
    • 練習量は質に転化する。写経大事。
    • 技術書の写経の仕方
      • 和田さんが昔書いたので、ググってみると。

今日何か一つ覚えて帰るなら

    • TDDと黄金の回転のイメージ
    • 自分が書いたコードにテストを書くのは、
    • プロとしての嗜み、という考えが自然になるようにしたい。
    • 先にテストを書くのがめんどくさい時は誰にでもある。
    • でもプロとしてやらねばならないこともある。