Skip to main content
組織にテストを書く
文化を根付かせる
戦略と戦術
和田 卓人 (@t_wada)
Feb 16, 2016 @ 日本OSS推進フォーラム
和田 卓人
id: t-wada
@t_wada
github: twada
gihyo.jpの連載
『[動画で解説]和田卓人の テスト駆動開発 講座』
http://gihyo.jp/dev/serial/01/tdd/
全20回すべて動画付き解説
ニコニコ動画でも見れます
WEB+DB過去記事の特設サイトと動画も
Do you write tests?
戦略編
• レガシーコード改善に正解はない
• テスト自動化は銀の弾丸ではない
• 導入方法にも銀の弾丸はない
• 導入を目的にしてはならない
• 状況は現場によって全て異なる
銀の弾丸は無い
ストレス
テスト
自動テスト
ストレス
テストを書く時間がないので
はなく、テストを書かないか
ら時間がなくなるのです。
James Grenning
• 文化の醸成は年単位の事業になる
• 「テストを書く時間がない」のでは
なく「テストを書かないから時間が
なくなる」
• 「動くコードに触れるな」と戦う。
触れなければコードは緩やかに死ん
でいく
文化を変える
動くコードに触れなければ死あるのみ
• ToBe ではなく AsIs と NotToBe からはじめる
• 隣の芝は青い。気にしないこと
• 人は自分の速度でしか成長できない
• プロジェクトもプロジェクトの速度でしか成長
できない
• 「まわりはもうみんなやっていますよ」は劇薬
なので用法用量を守って使うこと
イマココから始める
• 快不快で動く人、損得で動く人
• リファクタリングの快感
• 回帰テストのお得感
• メトリクスの達成感
• そしてビジネス価値
人を知る
• 人はそれぞれの度合いで変化に対して
身構える
• 前例がない、事例がない
• 「リファクタリングのジレンマ」
• リファクタリングを独立タスクにす
ると、そのタスクは着手されない
変えることの難しさ
事前に許可を得るより、あと
で許してもらう方が楽
Grace Hopper
It is easier to ask
forgiveness than it is
to get permission
• 仕様が固まることはない
• 開発が終わることはない
• 理解は常に深化する
• スキルも常に深化する
• 技術も常に進化する
すべては変化する
技術的負債の四象限
設計する時間がないん
だからしょうがない
今すぐリリースしない
といけない。あとでど
うにかしよう
レイヤー化? なにそ
れ?
もっとこうすべきだっ
たなぁ
無鉄砲 慎重
意図的
不注意
http://bliki-ja.github.io/TechnicalDebtQuadrant/
• 品質が「わかる」ようになる
• わかることこそ大事
• 体重計に乗るだけでは痩せない
• テストを書くだけでは、良くはならない
• 品質を上げるのは設計とプログラミング
• 再設計とリファクタリングをテストで支える
テストは品質を上げない
戦術編
• 「何が一番やばいですか?」
• 最も困っているところから
• お金、個人情報、……
• 新機能開発から
• バグ修正のところから
• 静的解析でピンポイントに
どこからやるか
• リスク
• 手動テストのコスト
• 自動化コスト
塹壕からのテスト戦術
• 一度に多くの人を変えるのは難しい
• 育てるのではなく、自ら育つように
• 教えられる人を増やす
• ペアプロで一人ずつ
• 若手のホープか、ベテランからか
だれとやるか
• 最初から全部やろうとしない
• テスト駆動にこだわるな
• テストファーストにこだわるな
• 「ユニット」テストにこだわるな
• テストの実行速度にこだわるな
• テストの網羅性にこだわるな
こだわるな
• 良いユニットテストの指標にも優先
度がある
• 再現、繰り返し可能 (Repeatable)
• 独立している (Independent)
• 他はそれからでいい
こだわろう
• 何はなくとも読むべし
• 「仕様化テスト」のススメ
• 「絞り込み点」を探す
レガシーコード改善ガイド
• 割れ窓理論
• メトリクスを取ろう
• カバレッジが低いうちは測定は効果大
• 小うるさいツールを乗りこなす
• 分母分子を見ない。時間を追った変化
を見る。傾きを見る。
見える化
• 動的テストと静的テスト
• 全体のメトリクスを計測して俯瞰の
視点を得る
• 部分的なメトリクスを計測し続けて
傾向を見る
• PMD, rubocop, Coverity,…
静的解析を使いこなす
• コードレビューのインフラに投資す
る
• github, gitlab, gitbucket
• WIP pull request
• コードを見る文化、見られる文化を
育てる
コードレビュー
• テストがないのは既に設計が悪い兆候
• 設計/実装を変えるのが前提
• 実装のテストを書かないこと
• テストがカバーする範囲に遊びを持た
せ、カバー範囲内をリファクタリング
• 状況に応じて E2E テストを使いこなす
設計の可動域を確保する
• サンプルとデモが大事
• 真似してもらう土台を作る
• 最初はサンプルのコピペでも良い
• テストのある生活を体験してもらう
ことが大事
• 次にテストのメンテナンスを学ぶ
背中を見せる
• できるからやるのではない
• やるからできるようになる
• あなたが書けるようにならなければ、
誰も書けるようにはならない
Social Change starts with YOU
テストはプロの嗜み
ご清聴ありがとうございました