TDD再考 (7) – テストはどこまで書けば良いのか？

• tdd – How deep are your unit tests? – Stack Overflow
  • http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests

「テストはどのレベルまで書けば良いのか？」という Stack Overflow の質問。明快な答えが出るような質問ではないので Stack Overflow ではオフトピックだとして既にロックされているが、「歴史的な意義がある」ということで残されている。

なぜ歴史的な意義があるかと言えば、TDDでテストを書こうとする人は誰でも抱くであろうこの疑問に対して、Kent Beck氏自らが回答しているのがその理由の一つだと思われる。そして、その回答が聴衆にとっては少なからず意外な内容だったことも、この質問の重要性に寄与している。

Beck氏の回答はシンプルである。

「私は機能するコードに対してお金を貰っているのであって、テストコードの対価を受け取っているわけではない。なので自分の哲学としては、テストにかける労力は必要な自信を得るための最小限度に抑えることにしている」

「必要な自信を得るための最小限度」は人によって異なるだろうし、チームで開発する場合は、チームを構成するメンバーのスキルや性格に依存することになる。つまり、完全にその人（チーム）次第になるということだ。

これはアジャイルの思想からすれば自然なことに思えるが、Beck氏の回答に対する反応を見る限り、少なからぬ驚きをもって受け止められているようである。「Kent Beckがこんな考えを持っていたなんて青天の霹靂である。TDDの信奉者は100%あるいはそれに準じる高いカバレッジ率を目指す傾向があって、Kent Beckも当然そうしていると考えているはずだ。」

Beck氏の回答に対して正面から反対している人もいる。コードは書いた本人だけでなく、事情を知らない他人がメンテナンスする可能性があり（そしてその人はその時点でチームのメンバーではないかもしれない）、当事者だけの文脈でテストの範囲を決めるのは良くないという指摘だ。あるいは、TDDはテストファーストが前提なのだから、一部分だけテストするということがそもそも成り立たないのではないか、等々。

別の回答では、TDDのT、つまり「テスト」という表現が「テストはきちんとやらなければいけない」という、TDDの本来の目的とは異なる品質保証の文脈を呼び込み、その結果としてカバレッジ云々の話になってしまうのではないかと指摘している。TDD界隈では頻繁に耳にする指摘である。その反省を踏まえて、BDD（Behavior Driven Development）というものが生み出された。