twadaさんの基調講演(@XP祭り)

和田さんが講演をした理由

TDDの歴史
- XPに詳しかった4人が中心で作り始められた
- 機内のペアプロでJUnitが誕生
お互いの得意分野を出し合ったペアプロ
- SUnit
- Java
- デザインパターン
- TDDという命名はどう生まれたのか
最初はTest Firstという名前だった
加えた要素
- インクリメントなデザイン
- リファクタリング
- Test-Driven Development は日本のソフトウェア開発には必要な存在だろう
和訳して、日本のソフトウェア開発界に一役買いたかった
- 要件はお客さんに近い方から生まれるから、外側から実装していきたい
ただ依存が多いドメインから実装しないと外側の機能のテストができない
そこで、Mockなどを用いたテストが生まれる
これが「依存方向逆転」の一種
和田さんのここまでの経緯
- テストを書かせたかった
簡単にテストを書けるtestingフレームワークを作ればいいってことで作成

正しくない解釈と意味の希薄化
- TDDの強要は、TDDを広げるための一番の妨げになる
- 「テスト書かずんば、人にあらず」は言い過ぎ
- testを書くだけでは、コードの品質は上がらない
無理やりテストを書くだけで、リファクタリングはしない
テストを書きづらいことはリファクタリングと再設計のチャンス
- test firstだけがTDDではない
- testだけ書かれて、リファクタリングされない
- Mockが柔軟に使えるようになって、testを通すためだけの便利な道具に成り下がった
Mock, Stub, Fake, Spyは違うよという話
違いを理解して、使い分けができる
- BDDの目的がテストを通すことになってしまった
本来はシステムの外から仕様を固めていくために使う
BDDをやることが目的だけではない
- テストのメンテナンスしている日々を送ると幸せの約束の地には行けない
メンテナンスコストがかかる
リファクタリングはしていく必要があるよ
TDDの本来の意味
- TDDの「T」はテストの一部でしかない
Agile Testing
- testではなく,checkingでしかないんじゃないか？
- テストがあることで自信のある状態で勝利の道を歩き始められる
- テストは目的であり、大いなる自信を持ってコードを書くための手段でしかない。