TDD再考 (1) – テストファーストとユニットテストへの死刑宣告

• TDD is dead. Long live testing. (DHH)
  • http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

いかにも物議を醸しそうな（そして実際に醸しまくった）この記事を、Ruby on Rails の作者である David Heinemeier Hansson (DHH) 氏が発表したのが去年の４月、ということはあれから既に一年以上が経過している訳で、今更感が若干漂うところではあるが、このシリーズ「TDD再考」では、このDHH氏の記事に端を発して行われた様々な主張や議論を振り返りながら、アジャイル以後のプログラムデザインについて再考してみたいと思う。

件の記事でDHH氏は、「TDDは死んだ」と高らかに宣言しているわけだが、まず始めに気をつけなければならないのは、DHH氏が言うところのTDDというものが、かなり極端な例を念頭に入れて想定されているという事である。それは彼が「fundamentalism（原理主義）」や「fanatical（狂信的）」のような強い言葉を使っている事からも伺われる。

彼の批判を紐解くとポイントは二つある。一つはテストファーストこそがプログラミングのあるべき姿であり、プログラムのクオリティはそれをいかに正しく実践しているかによって査定されるという考え方が蔓延した結果、実際にそれが有効かどうかとは関係なく、それを実践しているかどうかで技術者の値踏みが行われるようなってしまったということ（ドグマ化）。そして、二つ目は、厳密な意味でのユニットテストでTDDを実施してプログラムデザインを導出すると、必要以上の細分化（これは James Coplien氏による指摘）と間接化（大量のMockオブジェクト）によって、過剰な複雑化を招くという事である。

そして、テストファーストという実践は捨てて、ユニットテストよりもシステムテストの方に重心を移すべきだと提案している。ユニットテストの対抗として挙げられているのが、データベースアクセスも含む形で Rails の Active Record をテストする例や、Webブラウザ経由のテストを自動化するフレームワーク「Capybara」などである。

実際にアジャイルやTDDの実践者の話を思い返しても、彼らがDHH氏が言うところの厳密な意味でのユニットテスト（依存関係は全てMockにして、対象となるユニットだけをテスト対象にする）にこだわっている印象はない。むしろ、DHH氏と同様、過剰なMockの導入は無駄が多いし、本来テストすべき箇所をテスト出来ないという問題意識を持っている人が多いように思う。Mockにこだわるのは厳密な Outside-in デザインにこだわる Behavior Driven Development (BDD) の一派ではないだろうか。実際にオリジナルTDD派とBDD派にはそのような対立も散見される。

TDDがドグマ化しているという指摘が、この記事の主題であり、多くの人の興味と共感を得るきっかけとなった部分だと思われるが、仮にそれが正しいとして、何故このようなことが起きたと考えられるだろうか？　

まず、TDDが提案した、プログラムデザインとテストを一体化するという考え方のインパクトが大きかった事が挙げられるだろう。ここにはドグマ化の要因となる二つの要素があったと考えられる。一つは、DHH氏も指摘しているように、これまでのソフトウェア開発の中で主要な不作為の一つだと見られていた、テストを書かない・しないということへの処方箋だったこと。専門家はこういった不作為を特に厳しく糾弾する傾向がある。そして、更に重要だと思われるもう一つの要因は、それが「要求駆動」のデザイン手法だったという事である。

テストをやらないというのは、将来起こりえる問題への不作為であるが、ここを過剰に追求するのはアジャイルとは矛盾すると考える事もできる。以前取り上げた記事の事例では、リーンスタートアップ的な実験フェーズにおいてテストを省略するという話が紹介されていた。

TDDが要求駆動であることの意味は大きく、それはアジャイルにとっても主題になるが故に、TDDがアジャイル実践の基礎だと捉えられている事が多い。そして要求駆動というのは、ユーザー中心設計や顧客中心主義のような、今の時代にとっての最大のドグマと言ってよい領域に属する。そして、これらの逆算的思考というのは本質的に反論がしづらい。

⇒ TDD再考 (2) – 何故、ほとんどのユニットテストは無駄なのか？