RailsConfの後：私はまだTDDを学ぶべきですか？

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

おそらく、自動化された回帰テストの業界の残念な欠如を打破するための直感に反するラムとして、テストファーストを使用する必要がありました。たぶんそれは、ソフトウェア作成の日常業務の文字通りの説明を意図したものではないたとえ話でした。しかし、それがどのように始まったとしても、それはすぐに破損しました。不信者を打ち負かすためのハンマーとして使用され、彼らを専門家ではなく、ソフトウェアを書くのに適していないことを宣言します。リトマス試験。

十分。もういや。私の名前はDavidで、ソフトウェアのテストファーストは作成していません。私はそれについてこれ以上謝罪することを拒否します、ましてやそれを隠すことはありません。自動回帰テストに目を向けるためにTDDが行ったことに感謝していますが、設計の教義からずっと離れています。

…

はい、テストファーストは私には死んでいます。しかし、私はその墓の上で踊るのではなく、その貢献を称えたいと思います。それは私たちの歴史の中で重要な段階を示しましたが、それでも次に進む時が来ました。

すべてを読む価値がありますが、私はいくつかの要点を説明しました：

1. TDDは、自動回帰テストを促進するためのマインドハックです
2. 怒りのテスト-最初のレトリックは悲しみと絶望につながります
3. TDDは、オブジェクトの過度に複雑なWebと間接参照につながります
4. 単体テストよりも分離されたシステムテストを優先する必要があります
5. しかし、その好みを別の宗教に変えてはいけません
6. これらの理由から、テストファーストはもう使用すべき設計手法ではありません。

エッセイでは、これらのポイントのほとんどは一緒に結び付けられています。それらはそれ自体では意味がありますが、意図されているほど絡み合っていません。

それらを分解しない場合、1つのポイントを主張すると、実際には同意できない可能性のある他のポイントが想定されます。 これをTwitterの怒りと140文字の制限と組み合わせると、混乱、ストローマン、炎上戦争に陥ります。

代わりに、これらのポイントのいくつかについて個別に説明します。

TDDは、オブジェクトと間接参照の過度に複雑なWebにつながります

最近、Rubyテストコミュニティで「オブジェクトと間接参照の複雑なWeb」が好まれているのを目にしています。これは悪いことだと思います。 （これは、私が最初にJavaから実行した理由の1つです！）しかし、TDDが原因であることに同意しません。

私は10年近くTDDを行ってきましたが、データベースからテストを分離していません。コントローラーレベルの機能テストと堅牢な統合テストスイートも、実行速度がどれほど遅くても、私のテストスイート全体の貴重な部分です。

システムからテストを分離することは、単なる最適化です。 そしてYAGNIは、それはおそらくまだそれほど重要ではないと言います。さらに、個々のテストを最適化するのではなく、SSDとアプリのプリロードによって全体的な速度を向上させたいと考えています。

それでも、TDDはシステム設計に影響を及ぼします。

TDDはコードを有機的に成長させます。 これは素晴らしいことです！ただし、熟練したソフトウェア開発者は、TDDが設計したよりも見栄えの良いコードを記述できる場合があります。他のコードとより緊密に結合されている可能性があり、すべてのOODルールに準拠しているとは限りませんが、明確でわかりやすく、シンプルです。 （DHHピンポンにはいくつかの良い例があります。）

TDDは、何を構築しているのかを実際に理解する前に、オブジェクトAPI設計に固定することもできます。後でAPIを変更するのが難しくなります。 そして、その摩擦により、より悪い設計に落ち着く可能性があります。

Test-firstは、もう使用すべき設計手法ではありません

TDDは、柔軟で十分にテストされたコードを作成するための優れたツールです。ですから、私はこの点に全く同意しません。以前の記事でTDDの多くの利点についてすでに話しました：

• より柔軟でテスト済みのオブジェクトモデルを使用できます。
• システムは定義上テスト可能であり、将来のテストの作成コストを削減します。
• 開発プロセス全体でテストコストを償却し、見積もりをより正確にします。
• 次に何をするかを決める必要がないため、流れを維持できます。

これらの利点に加えて、練習に役立ちます テスト。常に最初にテストを作成するため、多くのテストを行うことになります 事後にテストしようとした場合よりも 。テストが実際に正しいかどうかがすぐにわかります（最初に失敗するため）。さらに、「今回」のテストをスキップする言い訳はありません。

怒りのテスト-最初のレトリックは悲しみと絶望につながります

完全に、100％同意します。はい、また投稿します。しかし、誰かがメリットについて知らないためにTDDを行っていない場合、またはその方法をまだ十分に学んでいない場合、または不快に感じる場合、正しいアプローチは彼らを恥じることではありません。 助ける それら。 TDDが役立つ場合は、それがどのように役立つかを示してください。彼らが興味を持っているなら、彼らが始めるのを手伝ってください。

TDDなしでコードを作成する方法を好むためにTDDを使用していない場合は、それらを許可します。

専門知識を構築するにつれて、ソフトウェアを開発するための独自の直感、独自の味覚、および独自の好みの技術を開発します。 そして、インターネットの議論は専門家にそれらのことを無視するように教えるつもりはありません。

したがって、ベストプラクティスのアイデアに従わなかったとして誰かを批判する場合は、学習能力を損なうか、無に叫ぶことになります。これは、最良の場合は時間の無駄であり、最悪の場合はあなたの大義を傷つけます。

では、TDDを継続する必要がありますか？

はい！絶対に学び、実践することをお勧めします。

私はテストの方法を教えてくれたTDDの功績を認めていますが、TDDを行うと、それでも大きなメリットが得られます。完璧ではありませんが、魔法のように優れたコードを作成するための鍵となる手法は1つではありません。

代わりに、新しいパターン、テクニック、ツールを学び続ける必要があります。 正しいと感じるので、適切な場所で適切なパターンを使用できるようになるまで、それらを適用する練習をしてください。 。

学習しながら、時間をかけてコードを変更、リファクタリング、および実験してください。古いコードと新しいコードを見てください。あなたより経験豊富な人にレビューしてもらいましょう。あなたはそれを良くしましたか？ それがあなたの成長の仕方です。