The Clean Coder ch5 Test Driven Development
- Test Driven Development
- The Jury Is In
- The Three Laws of TDD
- The Litany of Benefits
- What TDD Is Not
- 英語
Test Driven Development
- TDDはXP由来
- だが、スクラム等、他のアジャイル方法論のほとんどでも取り入れられている
- 非アジャイルでも取り入れられる
- 著者ボブおじさんがKent Beck (TDDの走り)と働いて衝撃を受けたという話
The Jury Is In
- 過去何年にもわたり、TDDに関するさまざまな議論や記事が展開されてきた
- 結論、TDDは機能する
- TDDは(プロとして)当たり前のこと
The Three Laws of TDD
- TDD三原則
- これらにより、開発サイクルが30秒そこらに制限される
- テストとプロダクションコードは抗体と抗原のような一対のもの
The Litany of Benefits
Certainty
- 著者がメンテナを務めるFitNesseの話
- 64,000行くらい
- うち単体テストが2,200件、28,000行くらい
- カバレッジ90%、90秒程度で終わる自動テストスイーツがある
- これが通れば、加えた変更が他の部分を壊していないことが「ほぼ確か」といえる
- どれくらい「確か」か？
- リリースできるくらいには！
ant releaseコマンド一撃で受け入れテストまで終わる
Defect Injection Rate
- FitNesseは1年間で20,000行追加、バグは17件だった
- ほとんどがうわべ上の(=ささいな?)もの
- 不具合埋め込みはとても少ないと言える
- 他にも不具合率が2倍、5倍、あるいは10倍減ったという報告がある
Courage
- ハチャメチャなコードを見つけたとする
- 綺麗にしたいが、何か壊しそうで怖くて触れない、となりがち
- 壊したら自分のせい
- 自動テストがあれば変更は怖くない
- 変更が怖くなくなれば、プログラマはコードを綺麗にするのである
- 綺麗なほうが理解しやすく、変更しやすく、拡張しやすいから
- シンプルになり、不具合も入りづらくなる
- コードベースは腐っていくのではなく改善していくようになる
- 【補】Boy Scout Rule
Documentation
- TDD三原則に則って書かれた単体テストはそれ自体がドキュメンテーションになる
- オブジェクトの生成方法
- 関数の(意味のある)呼び出し方
- 単体テストは最も低水準の設計資料
- あいまいでない
- 正確
- 読み手が理解できる
- 実行可能
Design
- 「テスト困難なまずい設計」を未然に防ぐ
- cf. テストを後から書こうとするとテスト困難だったりする
- 後から完全なテストを書くことはできない
- カバレッジを稼ぐことはできる
- が、問題解決後にテストを書くと、その問題に対して落ちるテストを欠いてしまう
The Professional Option
- TDDのメリットはここに挙げたとおり
- TDDを使わないのはアンプロフェッショナル
What TDD Is Not
- 従えば必ずうまくいくというものではない
- テストファーストでもまずいプロダクションコードは書けてしまう
- まずいテストも書けてしまう
- TDD三原則が非実践的・不適切なことも稀だがある
