TDDをするべきではない場合
TDDBC 福岡2をきっかけにTDDネタをしばらく書いてきたが、ひとまずこれで最後。
さてTDDに慣れてくるとコードに対してコントロールを握っている感覚がやみつきになり、何でもTDDでやりたくなることが実際にあるのだが、それが失敗や無駄を招くこともある。
そうした間違った万能感を抱かないように注意したい。
例えば再現性の低いものに対するテストは無駄が大きい。
増えたテストがかえって負債になってしまう可能性も考えられる。
次に短期間のプロジェクトでテスト環境構築に大きなコストがかかりすぎるケース。
これは環境構築にかけたコストを回収する前にプロジェクトが終わってしまう。あるいは環境構築のコストがスケジュール的なリスクを招く。
それからユーザビリティやゲームバランス調整やレーティング設計のようなテストできないものをテストしようとしてしまう場合もある。
こうした調整が頻繁に入るような分野で数値の計算が絡んでくるとテストできそうな気になってしまうのだが、そうしたものに対してテストを書いても報われない。何かの係数が変わるたびにテストコードとプロダクトコードを書き直すようなことをしているなら、おそらくそのテストには意味がない。
またGUIの操作のような自動化しにくいテストもTDDには不適である。(先人達の努力により自動化できるようになっていることもあるが)
TDDは強力だが万能ではない。
使い処を間違えないようにしたい。