TDD/BDDは不完全なユニットテストを招くか？

作者 Mike Bria , 翻訳者 近藤 修平 - (株)永和システムマネジメント 投稿日 2008年2月27日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

XP ,

アジャイル技術 ,

方法論 ,

Object Oriented Design ,

Pair Programming ,

TDD ,

Agile ,

プログラミング ,

Domain Driven Design ,

設計 ,

Fit/Fitnesse ,

BDD ,

テスト

Peter Ritchie氏は、TDD(source)やBDD(source)にこだわることで、良いユニットテストを書かなくなる傾向があるのではないか、という懸念を表明した(source)。特に「インタラクションテスト(interaction testing)」というマントラは、不完全なユニットテスト、すなわち、どのような条件下で利用されても稼働するユニット(オブジェクト)である、という証明ができていないテストをもたらすと述べている。Peter氏の考えで最も興味深いのは、TDDとBDDのそもそもの意図に対する反対意見と受け取れるところだ。

Peter氏の根底にあるのは、クラスの概念は現実世界の概念とは独立した抽象化の仕組みだということだ。これに従えば、良いユニットテスト(source) とは こうした現実世界とは独立しているクラスを検証することである。この考えは、以下のように、TDDとBDDが導こうとするものに異議を唱えることにつながる。

テスト駆動開発(TDD:Test Driven Development)とビヘイビア駆動開発(BDD:Behaviour Driven Development)が抱えている問題の一つは、TDDやBDDの実践者たちが、単なるシステムの一部のインタラクション重視していていることであり、実際には「ユニットテスト」なっていないことです。彼らは、TDDとBDDというマントラに夢中になっているので、木を見るばかりで森を見ていません。単調なテストに陥っているのです。ユニットテストとは独立した個々のユニット、アプリケーションの中でテスト可能な最も小さい部分をテストするものです。

WikipediaのBDDエントリ(source)にあった例を挙げ、Peter氏は彼の主張をうらずける事例として次のように述べている。

そのテストは42億9496万7296の可能性のうち、たった13ケースだけを詳しくテストしています。これらのテストは、特定のシステムにおいて期待された振る舞いについてはきちんとテストできているかもしれませんが、本当にEratosthenesPrimesCalculatorをユニットとして捉えた上でテストしているとは言えません。仮に、そのシステムが期待されたふるまいだけ許するシステムならば、これらのテストは、システムがきちんと動く証明になります。しかし、EratosthenesPrimesCalculatorが、何らかの状況で期待している振る舞い以外の使われ方をされるとしたら(本来クラスにコードをカプセル化するのは再利用が目的です)、EratosthenesPrimesCalculatorは充分に検証されたユニットであるとは言えません。

Wikipediaの例では、EratosthenesPrimesCalculatorというユニットの実用性と正統性は、現実世界で「エラトステネスのふるい」という名前が示すアルゴリズムの示す性質に依存している。この点こそが、TDD実践者達が訴えようとしている「ユニットの実用性は、使われる環境(システム)というコンテクストがなければ定義できない」というものだ。言ってしまえば、こういったTDD/BDDの「用途」を明らかにしたいということが実践者たちの願いであり、彼らは、TDD/BDDの主な恩恵とはPeter氏が言うところの「インタラクションテスト」であると言っている。JMockの作者の一人であるSeteve Freeman氏(source)は次のように述べている。

その(インタラクションテストでテストファーストする)考え方では、あるオブジェクトの依存関係性を排除してしまいます。例えば、DAOをモックにすることがあると思いますが、DAOはアプリケーションドメインに属するものではなくて、実装ドメインの一部なのです。

別の言い方をすると、TDD支持者の人の多くは、そもそもユニットテストを書くことの目的は、ユニットが何をすべきで何をすべきでないのかという明快に仕様化することだ、と主張するだろう。Mario Gleichmann氏による、TDDと契約による設計(Design By Contract)を比較している記事(source)で、次のように述べている。

テスト駆動開発(TDD)における手段としてのユニットテストの意味合いは、実装の正しさを検証することより、むしろユニットがどのように振る舞うべきか、という仕様を検証するものです。実際、TDDにおけるテストは(検証ではなく)仕様であり、開発を駆動していくものです。高まりつつあるビヘイビア駆動開発(BDD)に、こういった核となる考え方への回帰をみることができます。BDDとは簡潔で自然な方法で仕様(もちろん自動的な検証が可能な)を記述できる適切な語彙を探そうとする試みであり、コンポーネントがある特定の状況下でどのように振る舞うかに再び焦点をあてるものなのです。

よく「ユニットは、そのコンテクストによって定義される」と言われるが、ユニットテストはその名が示すように、システムの全体としての品質であったり使い道の指針を提供するわけではなく、開発中においては充分なレベルの受け入れテスト(source)が伴っている必要がある、ということを思い出すべきだ。JS Greenwood氏(source)は次のように述べている。

不十分な結合テスト、つまり全てが分離してテストされている状態です。- 構成要素がの境界が明確であり、分離されていいて、充分にテストされていて、そして適切な状態にあるシステムとして完了させることはできます。しかし、分離したユニットテストは、結合テストで補完されてない限り、どのような組み合わせであろうとグレー(というか黒に近い)な領域なのです。

原文はこちらです：http://www.infoq.com/news/2008/02/unit_tests_forests_n_trees