TDDはYAGNIに矛盾する？

programming

Joel on Softwareに面白そうな記事が載っていた。

とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。


さて、冒頭で Joel 氏はこう言っている。

Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests of all your code."

From Podcast 38 – Joel on Software

The Joel Test を読んだたくさんの読者が、Joel Test の13番目の項目として "Unit Testing" を加えるべきだと書いてきているようだ。すべてのコードに対して100％ユニットテストを用意するべきだと。

これ、アジャイル派はどう思うのかな。Joel Test に 100% の Unit Testing を加えるべきだと思う？


さらに、氏はこう続けている。

the whole idea of agile programming is not to do things before you need them, but to page-fault them in as needed.

アジャイルの考え方とは、事が必要になる前に手を出すのではなく、必要に合わせて page-fault することだ。

ここで page-fault と表現するところがニクい。OSのページング処理になぞらえて、必要になるまで遅延処理する、という意味だろう。

これはまさに、YAGNI - You Ain't Gonna Need It の思想だ。そして、氏はすべてのコードに対してユニットテストを用意しなくてはならないという規律は、YAGNIの思想と矛盾すると述べているように思う。

つまりこういうこと。

ユニットテストというのは変更に対してアジャイルに対応するために用意するものだ。その変更の必要がまだないうちから、すべてのコードに対してテストを用意するのはYAGNIの思想に反するのではないか。そのテストコードこそ You Ain't Gonna Need It ではないのか。

これは面白い問題提起だ。そして、僕はかなりの部分で Joel 氏に同意する。

以降の部分で、氏はオブジェクト指向設計の設計原則（principle）を過度に強要することの問題点も指摘している。つまり氏は、TDD にしても設計原則にしても、開発プロセスに対して過度に一律にエンジニアリングの規律を適用するのはおかしい、と指摘しているのだと思う。


以下、簡単な覚え書き。

  • ユニットテストや設計原則がうまく機能するシステムとしないシステムがある。
  • うまく機能するもの：
  • しかし、すべての個々のクラスにまで一律に適用するのはいかがなものか
    • テストの記述コストと、得られるベネフィットが釣り合わない場合がある
    • ある種の設計変更をすると、それに伴って全体の一割に及ぶテストコードが壊れてしまうことだってある
  • 私見：敢えて反論するならば、Joel氏の意見からは「testing が開発を drive する」という視点が抜けているとは思う。
    • ただし、僕自身が試してみた経験では、そこまで testing が開発を drive してくれるという感覚は得られなかった。