私がTDDを実践しない理由（翻訳）
私は「テストファースト」で作業することも、テストでコードの設計を支援することも、めったにありません。
最近の私は、37signalsである新しいことに取り組み始めました。何も決まっていない白紙の状態なので作業はすいすい進み、来る日も来る日もこってりしたプルリクを作成しています。会議に先立って早めに投げておきたいと思っていたプルリクには、もれなく以下が含まれていました。
ご覧のように、私はほとんどの場合テストを最後に書いていることが見て取れます。例外があるとすれば、テストを書くことで最短で結果をフィードバックできるときぐらいで、私の経験上、そうしたケースは製品そのものの作業よりもインフラ関連で行うことが多くなります。しかしそういう場合であっても、私はテストをシステム設計で活用しようとは思いません。私はTDD（Test-driven development: テスト駆動開発）の実践者ではありません。
私は、TDDがどのようなもので何を提供しなければならないかについてひと通り精通しています。かつてTDDというパラダイムが爆発的に流行した頃に全面的に取り入れましたが、ある時点からふっつりとTDDをやめました。やめた当初は罪悪感がありましたが、やがて安心を得ました。
TDDにも私の好きな部分がいくつかあります。TDDは、詳細を隠蔽してわかりやすいインターフェイスを提供するブラックボックスとしてシステムを外部から冷静に観察することを推進してくれます。過去記事にも書いたように、このことは、アプリの境界の外から内部のメソッドの最後の1つに至るまで、あらゆるレベルに適用すべき重要な設計原則であると私は思っています。それを実践するためにTDDが必要だとはまったく思いませんが、インターフェイスをその消費者の視点で考えるのはよいことだと思います。
一方で私は、TDDが推しているテストのスタイル（低速な依存関係をモックで塞ぐことで、非常に小さく高速なテストの作成を推奨する）について、強い警戒心を抱いています。自分の経験では、この手法はコストに対する見返りが非常に小さいのです。数年前に、私の好きなテストについて記事を書いたことがありました。要約すると、私は可能な限り「本物をテストしたい」のです。
TDDには、もうひとつ危険な側面があります。「独立してテスト可能な部品を作ることを重視していれば、システムの設計はよくなるものだ」という気持ちにさせられるのです。私は、優れたシステム設計は（程度の差はあれ）テスト可能でなければならないと思いますが、その逆は必ずしも正しいとは思いませんし、あらゆる部品のテストが互いに独立していなければならないとも思いません。
1秒以内で完了する数千件もの完璧なテストがあらゆる部品に備わっていたとしても、できあがったシステムの設計が無残なことになる可能性もあるのです。
それに、あらゆるモジュールを一切の依存関係なしにテスト可能にしようとすると、あらゆるモジュールにインジェクションや間接参照が導入されて手痛いしっぺ返しを食らうのではないかという懸念もつきまといます。
私は、設計がよくなるか悪くなるかは、TDDを使うかどうかとは無関係だと信じています。ただ、多くの人が擁護しているような両者の確固たる因果関係があるとは思えないのです。
しかし何よりも、TDDでどうしても肌に合わない点は、何かと喧伝されている実用性が現実には欠けていることです。TDDは、特定の状況下で使われる道具として紹介されることはほとんどなく、むしろソフトウェア構築方法を推進する設計技法としてお披露目されています。こうした説明とTDDがもたらす作法が相まって、TDDを絶対視する独善性やそれに伴うあらゆるネガティブなものが引き寄せられてきます。
TDDの話になると、TDDを実践する人も否定派の人もひどく興奮してしまいます。私自身はTDDを実践するつもりは毛頭ありませんが、多くの場面でうまく行っていることも認識しています。TDDを絶対視する気配が漂ったり、他のプロ開発者たちを攻撃するようなことがない限り、私にとって何の問題もありません。単にTDDは私の使うツールではないと思っているだけです。
概要
元サイトの許諾を得て翻訳・公開いたします。
日本語タイトルは内容に即したものにしました。