TDD再考 (3) – TDDが解決しようとした問題は何か？

DHH氏の「TDD is dead」を受けて、TDDの生みの親である Kent Beck氏が Facebook に投稿した記事。

いささかアイロニカルな反論ではあるが、TDDが解決していた（とBeck氏が考える）問題の一覧が挙げられているので、以下にまとめておく。

過剰性能（Over-engineering）
- どうやって作り過ぎに対応するか？
- アジャイルでいう YAGNI
- 要件を満たす最低限の実装に留める（Just enough）
APIフィードバック
- API設計の妥当性をどのように検証するか？
- プログラムを利用者視点（API視点）でデザインできる
論理エラー
- コンパイラでは捕捉出来ないエラーをどうやって発見・防止するか？
ドキュメンテーション
- プログラム（API）の利用方法をどのように伝えるか？
大きな問題
- 一度に解決しようとするとハマってしまいそうな大きな問題にどう立ち向かうか？
- 簡単に解ける小さな問題を積み上げていく（小さなステップ）
インタフェースと実装の分離
- どうやってAPIが実装依存にならないようにするか？
問題共有
- どうやってプログラマ同士の問題共有を正確に行うか？
不安
- どうやってプログラムが期待通りに動作している事を確認するか？

このようにして、TDDが解決しようとしていた問題点を並べてみると、問題そのものの妥当性にはそれほど異論はないように思えるが、その解決策については必ずしもTDDに限る必要はないようにも思える。前回の記事に書いたように同じ価値を実現できるなら、必ずしも誰もが同じ方法をとる必要はない。

テストを先に書かなくても、一つ一つのステップを小さくする事は出来るし、小刻みな Test-Last アプローチでも、API視点でプロダクトコードを検証する事は出来る。エラーの抑止、リグレッションテスト、あるいはドキュメンテーションという観点から言えば、テストをいつ書くかは問題にならないはずである。

あるいは、DHH氏やJames O Coplien氏が指摘しているように、ユニットテストにフォーカスし過ぎる事は、より重要で本質的な問題、つまりビジネス価値の軽視につながる可能性もある。これは、TDDの手法そのものではなく、その問題設定に対する疑義である。