電卓祭りには乗り遅れたので、こちらは遅れないように..って遅れているかも。
私もテストドリブン万能主義は行き過ぎだと考えています。(勿論メソッドやプロパティ単位のテストは必要です。)
テスト仕様書を書くためには設計段階でメソッド単位の設計が完成している事が前提になります。これはウォーターフォールの思想のような感じがしてならないのです。
一つのモジュールの開発は、クラス構築を考えて製造に取り掛かりますが、途中で考えの稚拙さに気づき、インターフェースに変えたり、より小さいクラスに展開して継承関係を変えたりすることが多いので、都度テスト仕様を作るのは面倒です。
業務アプリは業務仕様を分析して開発単位を確定していきます。サブシステム化=>サブサブシステム化=>業務面から見た細部クラス。
実装レベルでは細部クラスを実装しやすいようにHas a なり is a なりで実装するので業務からみた単位と異なります。
製造に入る前に仕様が決まるの筈なので、業務面から見た細部クラスのテストケースを洗い出して、それをテスト中心というのなら納得です。
「書いたソースはすべて通るテストする」というのも疑問を感じます。
Private Sub 被テスト(ByVal 引数 As String)
Select Case 引数
Case "1"
'xxx
Case "2"
'xxx
Case Else
Debug.Assert(False, "ロジックエラー:引数の設定ロジックがバグっている") '<== ★
End Select
End Sub
このメソッドがあるとします。業務的には引数は "1"か"2"しか発生しません。
Case Elseの文(★)は論理的には不要です。
しかしロジックバグが自己検出しやすいようにこの手の文はあちこちに埋め込むのが好いと考えます。
"書いたソースはすべて通る" という意味とは矛盾することになるので疑問に感じるのです。
もちろん
if 1=1 then
xxxx
eles
yyyy
end if
の場合はyyyyは決して実行されませんし駄目ですが、上記とは意味合いが違うと考えています。
システムは単体の集まりではないです。完璧な単体を集めてもシステムは完璧にはなりません。
逆に不完全な単体を集めても欠点を熟知して補完する仕組みを加えれば格好は付きます。(本来は駄目なんですが、お手上げよりましでしょう)
クラス単位で業務仕様/例外を満たすか否かのテスト駆動で十分だと考えるのです。(もちろんソースは綺麗に書いてね)