この「TDD再考」シリーズの第三回で「TDD is dead」に対する Kent Beck氏の反応を紹介したが、今回は Martin Fowler氏の反応について検討してみたい。この後、David Heinemeier Hansson, Kent Beck, Martin Fowlerの三者は「Is TDD Dead?」という対談を展開して行くことになる。
「TDD is dead」が公開されて激しく燃え上がっている中、Fowler氏はまず「UnitTest」というタイトルの記事を自身のサイトに投稿している。
この記事の中でFowler氏は、DHH氏の記事の内容には直接触れずに、そもそもユニットテストの定義って何なのだろうという話を展開している。それは、DHH氏やJames O Coplien氏の批判の矛先がユニットテスト（の価値）にあり、議論に先立ってまずユニットテストってそもそも何なの？ という部分をはっきりさせておきたいということがあったのだろう。
まず、ユニットテストと言った場合、それが低レベルかつシステムの中の小さなパーツを対象としていること、基本的にはプログラマー本人によって書かれること、といった部分については多くの人の同意を得られそうであるが、それとは反対に、最も意見の食い違いが発生する部分が「コラボレーター」をどのように扱うかという問題だと言う。
とあるモジュールをテストする場合、そのモジュールが単独で機能するケースはどちらかと言えば少なく、何らかの依存するモジュールが必要となる場合が多い。この依存モジュールを「コラボレーター」と呼ぶ。ユニットテストは「ユニット」つまり単体のモジュールを対象としているのだから、コラボレーターはテストの対象から切り離すべきであり、そのためにモックオブジェクトを積極的に利用すべきだというのが Mockist style と呼ばれる勢力で、反対にコラボレーターも一緒にテストしてしまって問題ない、あるいはむしろそうすべきだと考える勢力を Classsic style と呼ぶ。
Fowler氏は Classsic派だったので、コラボレーターを切り離さないのはユニットテストの定義から外れるのではないかと批判されたそうだが、テストのターゲットはあくまでユニットの振る舞いであり、その内部構造は問題でないと考えているようだ。
Indeed this lack of isolation was one of the reasons we were criticized for our use of the term “unit testing”. I think that the term “unit testing” is appropriate because these tests are tests of the behavior of a single unit. We write the tests assuming everything other than that unit is working correctly.
ここで筆者はうーんと考え込んでしまった。
Fowler氏自身が書いているように、何をユニットと見なすかは状況に依存するので、いわゆる振る舞いがユニットを形成してさえいれば、その内部構造がいかに複雑であっても、それをユニットと見なせる可能性があるということだ。これはシステムというものが基本的には入れ子の構造になっていることを考えると当然のことだとも言える。概念的には入れ子のどこを切ってもユニットになり得る。
となると、もはやユニットという言葉に意味はないような気がしてくる。それよりも、どのようなタイプのインタフェースに対してテストをするのか（プログラムモジュールなのか、REST APIなのか、UIなのか）、コラボレーターのセットアップにどれぐらいの手間や時間がかかるのか、そしてそのコストはプロジェクトにとって許容範囲内なのか、というような指標の方がテストというものを分類するためには適切なように思える。
ゆびてく 