テストは、しさえすればバグがなくなるわけじゃなく、
バグ(デグレ)を潰すために計画的に仕掛けなけりゃならない。
じゃぁ、どうやって計画的に仕掛けるか。
当然本体のロジック/実装前に、そのロジック/実装はどう検証できるか、検証容易なロジック/実装を選択しなきゃならない。
加えて、他のロジックや実装に影響を受けないように、可能な限り(いろんなレベルで)分離しておいたほうがいい。他の実装が変わるたびにテストを書き換えるなんて、ヤボ。
業務ロジックレベルでも、具体的な実装を相手にするんじゃなく、インターフェイス(trait/protocol)を使って抽象化したものを相手にすべきだし、具体的な実装はこのインターフェイス相手のレベルのテストを用意しておけば、実装差し替えの場合でも必要十分な条件がテストできるはず。
ロジックや実装の前にテスト容易性を検討して、実テストを用意するというのは、だいたいTDD。
可能な限り分離(モジュール化)は、その指針/手段としてドメイン指向、オブジェクト指向。
とか。
TDDをやれば、ドメイン指向、オブジェクト指向の手順を守れば快適なクオリティコントロールができる、わけじゃなく、クオリティコントロールという目的のために必要な指針/手段/手順を導入しなきゃいけないってことだ。
# まぁ、今関わってるプロジェクトがこれの正反対でね。
アジャイルだって、後から後から増えてくる儀式だけを漫然と網羅的に実行したって、面倒臭いだけでしょ。
今、このチーム/プロジェクトの円滑な運営のために必要なことをやりゃいいんだから。