1. 組織にテストを書く
文化を根付かせる
戦略と戦術
和田 卓人 (@t_wada)
Feb 16, 2016 @ 日本OSS推進フォーラム

2. 和田 卓人
id: t-wada
@t_wada
github: twada

3. gihyo.jpの連載
『［動画で解説］和田卓人の テスト駆動開発 講座』
http://gihyo.jp/dev/serial/01/tdd/
全20回すべて動画付き解説
ニコニコ動画でも見れます
WEB+DB過去記事の特設サイトと動画も

5. Do you write tests?

6. 戦略編

7. • レガシーコード改善に正解はない
• テスト自動化は銀の弾丸ではない
• 導入方法にも銀の弾丸はない
• 導入を目的にしてはならない
• 状況は現場によって全て異なる
銀の弾丸は無い

8. ストレス
テスト

9. 自動テスト
ストレス

10. テストを書く時間がないので
はなく、テストを書かないか
ら時間がなくなるのです。
James Grenning

11. • 文化の醸成は年単位の事業になる
• 「テストを書く時間がない」のでは
なく「テストを書かないから時間が
なくなる」
• 「動くコードに触れるな」と戦う。
触れなければコードは緩やかに死ん
でいく
文化を変える

12. 動くコードに触れなければ死あるのみ

13. • ToBe ではなく AsIs と NotToBe からはじめる
• 隣の芝は青い。気にしないこと
• 人は自分の速度でしか成長できない
• プロジェクトもプロジェクトの速度でしか成長
できない
• 「まわりはもうみんなやっていますよ」は劇薬
なので用法用量を守って使うこと
イマココから始める

14. • 快不快で動く人、損得で動く人
• リファクタリングの快感
• 回帰テストのお得感
• メトリクスの達成感
• そしてビジネス価値
人を知る

15. • 人はそれぞれの度合いで変化に対して
身構える
• 前例がない、事例がない
• 「リファクタリングのジレンマ」
• リファクタリングを独立タスクにす
ると、そのタスクは着手されない
変えることの難しさ

16. 事前に許可を得るより、あと
で許してもらう方が楽
Grace Hopper
It is easier to ask
forgiveness than it is
to get permission

17. • 仕様が固まることはない
• 開発が終わることはない
• 理解は常に深化する
• スキルも常に深化する
• 技術も常に進化する
すべては変化する

18. 技術的負債の四象限
設計する時間がないん
だからしょうがない
今すぐリリースしない
といけない。あとでど
うにかしよう
レイヤー化？ なにそ
れ？
もっとこうすべきだっ
たなぁ
無鉄砲 慎重
意図的
不注意
http://bliki-ja.github.io/TechnicalDebtQuadrant/

19. • 品質が「わかる」ようになる
• わかることこそ大事
• 体重計に乗るだけでは痩せない
• テストを書くだけでは、良くはならない
• 品質を上げるのは設計とプログラミング
• 再設計とリファクタリングをテストで支える
テストは品質を上げない

20. 戦術編

21. • 「何が一番やばいですか？」
• 最も困っているところから
• お金、個人情報、……
• 新機能開発から
• バグ修正のところから
• 静的解析でピンポイントに
どこからやるか

22. • リスク
• 手動テストのコスト
• 自動化コスト
塹壕からのテスト戦術

23. • 一度に多くの人を変えるのは難しい
• 育てるのではなく、自ら育つように
• 教えられる人を増やす
• ペアプロで一人ずつ
• 若手のホープか、ベテランからか
だれとやるか

24. • 最初から全部やろうとしない
• テスト駆動にこだわるな
• テストファーストにこだわるな
• 「ユニット」テストにこだわるな
• テストの実行速度にこだわるな
• テストの網羅性にこだわるな
こだわるな

25. • 良いユニットテストの指標にも優先
度がある
• 再現、繰り返し可能 (Repeatable)
• 独立している (Independent)
• 他はそれからでいい
こだわろう

26. • 何はなくとも読むべし
• 「仕様化テスト」のススメ
• 「絞り込み点」を探す
レガシーコード改善ガイド

27. • 割れ窓理論
• メトリクスを取ろう
• カバレッジが低いうちは測定は効果大
• 小うるさいツールを乗りこなす
• 分母分子を見ない。時間を追った変化
を見る。傾きを見る。
見える化

28. • 動的テストと静的テスト
• 全体のメトリクスを計測して俯瞰の
視点を得る
• 部分的なメトリクスを計測し続けて
傾向を見る
• PMD, rubocop, Coverity,…
静的解析を使いこなす

29. • コードレビューのインフラに投資す
る
• github, gitlab, gitbucket
• WIP pull request
• コードを見る文化、見られる文化を
育てる
コードレビュー

30. • テストがないのは既に設計が悪い兆候
• 設計/実装を変えるのが前提
• 実装のテストを書かないこと
• テストがカバーする範囲に遊びを持た
せ、カバー範囲内をリファクタリング
• 状況に応じて E2E テストを使いこなす
設計の可動域を確保する

31. • サンプルとデモが大事
• 真似してもらう土台を作る
• 最初はサンプルのコピペでも良い
• テストのある生活を体験してもらう
ことが大事
• 次にテストのメンテナンスを学ぶ
背中を見せる

32. • できるからやるのではない
• やるからできるようになる
• あなたが書けるようにならなければ、
誰も書けるようにはならない
Social Change starts with YOU

33. テストはプロの嗜み
ご清聴ありがとうございました