RailsConfの余波——それでもTDDを学ぶべきか？

TDDについて私はこれまで数多くの記事を書いてきました。そんな中、前回の記事を公開したのが、David Heinemeier Hansson（DHH）がRailsConfの基調講演でTDDに言及した瞬間とほぼ同時だったこともあり、いくつか質問を受けました。

DHHのTDDに関する見解に同意しますか？今でもTDDを推奨していますか？もし推奨しないなら、代わりに何をすべきですか？

DHHが語ったこと

基調講演を見逃した方のために、DHHのエッセイがその要点を捉えています：

おそらく、業界における自動化されたリグレッションテストの悲惨な欠如を打破するために、テストファーストという直感に反する破城槌が必要だったのでしょう。あるいは、ソフトウェア開発の日々の実践を文字通りに記述することを意図していない寓話だったのかもしれません。しかし、それが何であれ、やがてそれは堕落しました。信じない者たちを打ちのめし、彼らをプロフェッショナルではなく、ソフトウェアを書くに値しないと宣言するハンマーとして使われたのです。リトマス試験として。

もう十分です。これ以上はありません。私の名前はDavidです。そして私はテストファーストでソフトウェアを書きません。もうそのことを謝罪するつもりも、隠すつもりもありません。自動化されたリグレッションテストへの目を開かせてくれたことには感謝していますが、設計のドグマからはとうに卒業しました。

…

そう、テストファーストは私にとって死んだものです。しかし、その墓の上で踊るよりも、その貢献を称えたい。それは私たちの歴史における重要な段階でしたが、前に進む時が来たのです。

全文を読む価値がありますが、主なポイントを抜粋すると：

1. TDDは自動化されたリグレッションテストを促進するためのマインドハックである
2. 攻撃的なテストファーストのレトリックは悲しみと絶望をもたらす
3. TDDは過度に複雑なオブジェクトの網目と間接参照を生み出す
4. ユニットテストよりも分離されたシステムテストを優先すべきである
5. しかし、その優先を別の宗教にしてはならない
6. 以上の理由から、テストファーストはもはや使うべき設計手法ではない

エッセイの中で、これらのポイントの多くは互いに関連付けられています。それぞれ単独では理にかなっていますが、提示されているほど相互に絡み合っているわけではありません。

これらを切り離さないまま議論すると、あるポイントについて論じることが、実際には同意していないかもしれない他のポイントを前提とすることになります。そこにTwitterでの怒りと140文字の制限が加わると、混乱、ストローマン（藁人形論法）、炎上につながります。

そこで、ここではいくつかのポイントを個別に取り上げてみたいと思います。

TDDは過度に複雑なオブジェクトの網目と間接参照を生む？

最近、Rubyテストコミュニティにおいて「複雑なオブジェクトの網目と間接参照」への傾倒を目にすることがあります。これは良くないことだと思います（私が元々Javaから逃げ出した理由の一つです！）。しかし、それがTDDによって引き起こされるとは思いません。

私は10年近くTDDを実践してきましたが、テストをデータベースから分離していません。コントローラーレベルの機能テストや堅牢な統合テストスイートも、どれだけ実行が遅くても、テスト全体の中で価値のある一部です。

システムからテストを分離することは、単なる最適化です。YAGNIの原則に従えば、現時点ではそれほど重要ではないでしょう。そもそも、個々のテストを最適化しようとするより、SSDやアプリのプリロードによる全体的な高速化の方が効果的です。

とはいえ、TDDはシステム設計に影響を与えます。

TDDはコードを有機的に成長させます。これは素晴らしいことになり得ます！しかし時には、熟練した開発者が書いたコードの方が、TDDが導く設計よりも見通しの良いことがあります。他のコードとの結合度が高かったり、オブジェクト指向設計の原則に厳密に従っていなかったりしても、明確で、率直で、シンプルなのです。（DHH Ping Pongには良い例があります）

また、TDDは本当に作ろうとしているものを理解する前に、オブジェクトAPIの設計に縛られる可能性があります。後からAPIを変更するのが難しくなり、その摩擦が、より劣った設計への妥協を招くこともあります。

テストファーストはもはや使うべき設計手法ではない？

TDDは柔軟でよくテストされたコードを作るための素晴らしいツールです。だからこそ、この点には完全に反対します。以前の記事でTDDの多くの利点についてすでに述べました：

• より柔軟で、テスト済みのオブジェクトモデルが手に入る。
• 定義上、システムはテスト可能であり、将来のテストを書くコストが下がる。
• テストのコストを開発プロセス全体に分散できるため、見積もりがより正確になる。
• 次に何をすべきか決める必要がないため、フロー状態を保てる。

これらの利点に加えて、TDDはテストの練習にもなります。常にテストを先に書くため、事後にテストを書こうとする場合よりも、はるかに多くのテストを書くことになります。テストが正しいかどうかすぐにわかります（最初に失敗するからです）。さらに、「今回だけ」とテストをスキップする言い訳もできません。

攻撃的なテストファーストのレトリックは悲しみと絶望をもたらす

これには100%同意します。そう、また同じことを言います。しかし、誰かがTDDをしていないのは、その利点を知らないから、やり方をまだ習得できていないから、あるいは慣れないと感じているからだとしたら、正しいアプローチは恥をかかせることではなく、助けることです。TDDがあなたにとって役立っているなら、どう役立っているかを見せてあげてください。興味を持ったら、始める手助けをしてあげましょう。

もしTDDを使わない方がコードの出来が良いと考えているなら、それを尊重しましょう。

専門性を深めていくと、独自の直感、独自の審美眼、独自の好みの開発技法が育まれます。インターネット上の議論で、専門家がそれらを無視するようになることはありません。

つまり、自分の考えるベストプラクティスに従わない人を批判するなら、相手の学習を妨げるか、虚しく叫んでいるだけかのどちらかです。最善の場合でも時間の無駄であり、最悪の場合は自分の主張そのものを傷つけます。

それでもTDDを続けるべきか？

はい！学び、実践することを強くお勧めします。

私がテストの書き方を学べたのはTDDのおかげだと思っていますし、今でもTDDを実践すれば大きな恩恵を受けています。完璧な手法ではありませんが、より良いコードを魔法のように生み出す唯一の鍵となる技法など、そもそも存在しません。

大切なのは、新しいパターン、技法、ツールを学び続けることです。それらを適用する練習を重ね、しっくりくる場面で正しいパターンを選べるようになりましょう。

学ぶ過程では、時間をかけてコードを修正し、リファクタリングし、実験してみてください。古いコードと新しいコードを見比べ、経験豊富な人にレビューしてもらいましょう。より良くなりましたか？それがあなたの成長の道です。