組織にテストを書く文化を根付かせる

戦略と戦術

和田 卓人 (@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

テストはプロの嗜み

ご清聴ありがとうございました