TDDは品質担保のためでは無い？

TDD談義への反応に対する雑感 - 千里霧中

自分はTDDすらやったことの無い、ある意味時代遅れの開発しかやったことはないのだけど、先のエントリを読むとTDDのテストと単体テストは別物という解釈らしい。

それを聞いたとき、「？」と思ったのが本音だ。テストコードなのに品質とは関係ないのだろうか？と。

TDDに対する私なりの解釈

私はある関数のコードを書くときにJavadocやDoxygenで関数ヘッダをある程度詳しく文章で書く。

そして関数内にコメントの形式でどんなコード（処理）を実装すべきかを書いていく。イメージとしては以下のような感じ。

private List<nnnn> func(int id) {
    // xxオブジェクトのインスタンス取得
    // XXXDAO経由でidに関連するデータを取得
    // 取得したデータからxxxとxxxの条件に合致するものを抽出しリストにする
    // リストを生成し返す
}

あとは上記のコメントを実際のコードに置き換えて行けばよい。また自分以外のメンバーに作ってもらうときもこの形式で渡すこともある。

ただこの方式だと、単に文章をコードに置き換えただけでそのコードが正しく動作するものかどうかを検証する手段がない。

なので、上記のようなコメントを先に書く代わりにTDDのテストコードを書いて、その通りに関数本体側を実装する。そうすると、

• この館数ではどういうコード（処理）を書くべきかの情報が残せる（コメントで残すのと同じ）
• 実装したコードが意図した動作をしているか"実行して"評価することができる

という2点が一緒に満たせるというのがTDDというものなのかな、と。

実際に境界値評価だったり網羅性の評価を行う"単体テスト"の場合は、もっとしっかりとテストコードを書く必要があるのだと思うし、その単体テストコードのベースがTDDのテストコードであることは問題無いということだろうか。

TDDと単体テストコードは、誤解を恐れずに言えば前者が"コーディングの補助"、後者が"品質の担保"ということになるのだろうか。

感想

TDDのテストコードが品質担保（これだけでは単体テストとしては不十分で使えない）とすると、開発工数の見積もりにTDDのコーディング工数を入れるのは、TDDに理解の無いSIerなどでよくある開発現場だと説明するのが難しいかもしれないね。

何も言わずに実装工数見積もりの中に含めてしまうか、単体テストコードへ昇華させることを視野に説明して見積もりに乗せるかということになるだろうか。

個人的には、TDDだけならやる意味は少し薄いのかなという気持ちはある。TDDのテストコードを単体テストコードへ昇華させるという前提でやるなら、取り組む価値はあるかと思っている。