流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。氏が発表したのが去年の4月、ということはあれから既に一年以上が経過している訳で、今更感が若干漂うところではあるが、このシリーズ「TDD再考」では、このDHH氏の記事に端を発して行われた様々な主張や議論を振り返りながら、アジャイル以後のプログラムデザインについて再考してみたいと思う。件の記事でDHH氏は、「TDDは死んだ」と高らかに宣言しているわけだが、まず始めに気をつけなければならないのは、DHH氏が言うところのTDDというものが、かなり極端な例を念頭に入れて想定されているという事である。それは彼が「fundamentalism(原理主義)」や「fanatical(狂信的)」のような強い言葉を使っている事からも伺われる。彼の批判を紐解くとポイントは二つある。一つはテストファーストこそがプログラミングのあるべき姿であり、プログラムのクオリティはそれをいかに正しく実践しているかによって査定されるという考え方が蔓延した結果、実際にそれが有効かどうかとは関係なく、それを実践しているかどうかで技術者の値踏みが行われるようなってしまったということ(ドグマ化)。Coplien氏による指摘)と間接化(大量のMockオブジェクト)によって、過剰な複雑化を招くという事である。テストファーストという実践は捨てて、ユニットテストよりもシステムテストの方に重心を移すべきだと提案している。テストする例や、Webブラウザ経由のテストを自動化するフレームワーク「Capybara」などである。実際にアジャイルやTDDの実践者の話を思い返しても、彼らがDHH氏が言うところの厳密な意味でのユニットテスト(依存関係は全てMockにして、対象となるユニットだけをテスト対象にする)にこだわっている印象はない。DHH氏と同様、過剰なMockの導入は無駄が多いし、本来テストすべき箇所をテスト出来ないという問題意識を持っている人が多いように思う。一派ではないだろうか。実際にオリジナルTDD派とBDD派にはそのような対立も散見される。TDDが提案した、プログラムデザインとテストを一体化するという考え方のインパクトが大きかった事が挙げられるだろう。ここにはドグマ化の要因となる二つの要素があったと考えられる。一つは、DHH氏も指摘しているように、これまでのソフトウェア開発の中で主要な不作為の一つだと見られていた、テストを書かない・しないということへの処方箋だったこと。専門家はこういった不作為を特に厳しく糾弾する傾向がある。重要だと思われるもう一つの要因は、それが「要求駆動」のデザイン手法だったという事である。テストをやらないというのは、将来起こりえる問題への不作為であるが、ここを過剰に追求するのはアジャイルとは矛盾すると考える事もできる。以前取り上げた記事の事例では、リーンスタートアップ的な実験フェーズにおいてテストを省略するという話が紹介されていた。TDDが要求駆動であることの意味は大きく、それはアジャイルにとっても主題になるが故に、TDDがアジャイル実践の基礎だと捉えられている事が多い。要求駆動というのは、ユーザー中心設計や顧客中心主義のような、今の時代にとっての最大のドグマと言ってよい領域に属する。これらの逆算的思考というのは本質的に反論がしづらい。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。