TDDとTest First Development（またはTest First Programming）の間に違いはありますか？
どちらのアイデアも私と非常によく似ていますが、微妙な違いやまったく同じことが、さまざまな方法で説明されている可能性があります。 TDDとテストファースト開発/プログラミングの関係は何ですか？
推進要因とは何かという点で違いがあります。
クラス（またはシステム-これはもちろんさまざまなスケールで発生する可能性があります）がどのように見えるべきかについて漠然とした考えを持っていますか？それから実際の形を与えるテストを考えますか？それがTDDです。
クラスのパブリックAPIがどうあるべきかを正確に知っており、実装前にテストを作成するだけですか？これがテストファースト開発です。
私のスタイルは、2つの混合物になる傾向があります。テストを作成する前にAPIがどうあるべきかが明らかな場合があります。他の場合では、テスト容易性が実際に設計を推進します。
言い換えれば、TDDは「どのような質問をしたいですか？」から始まります。一方、非TDD（最初にテストを行うかどうかに関係なく）は「どのような答えを出したいですか？」で始まります。
これらは基本的に同じことを表す異なる名前です。最後のDは開発だけでなく設計も表すことができるため、実際には5つの名前です。
Test Firstは、特にエクストリームプログラミングのコンテキストで、テスト-コード-リファクタリングサイクルに最初に使用された用語でした。 Test Driven Developmentという名前が提案され、すぐに採用されました。これは、TFDがテスト戦略ではなく、常にデザイン戦略であるという事実を強調するためです。
明らかに今日、これら2つの用語の意味合いが異なる人もいますが、それは彼らの存在の背後にある意図ではなく、私はそれが常識であることに依存しません（そうではないため）。実際、TFDという用語は非推奨と見なしたいと思います。
テストファーストプログラミング、テストファースト開発、テストドリブン開発、さらにはテストドリブンデザインのような多くの類似した用語があります。いくつかの点を明確にすることが重要です：
1。テストファーストプログラミング（TFP）
テストファーストプログラミングという用語は、プログラミングのベストプラクティスです。 Kent Beckの著書「ExtremeProgrammingExplained」で（造語されていない場合）再紹介されました。「プログラミングの前に単体テストを作成し、すべてのテストを常に実行し続けてください」。したがって、テストファーストプログラミングについて話すときは、これらのテストを満たすコードを書く開発者が自動ユニットテストを書くことを指します。ユニットテストは、定期的に実行できる自動回帰テストスイートを積み上げて構築します。
2。テスト駆動開発（TDD）
テスト駆動開発（TDD）は、ケントベックが著書「例によるテスト駆動開発」で紹介した方法論の名前です。これはソフトウェア開発プロセスであり、コードの前にテストを記述するだけではありません。本全体は、パターン、ワークフロー、文化などによってそれを説明しようとしています。その重要な側面の1つは、リファクタリングに重点を置いていることです。
一部の人々は、テストファースト開発、テスト駆動設計、またはテスト駆動プログラミングという用語を使用します... 1つ確かなことは、確立された方法論はテスト駆動開発であり、プログラミング手法はテスト優先プログラミングです。残りは、一般的にコードの前にテストを書くという考えを参照しているか、テスト駆動開発またはテストファーストプログラミングを誤って参照しています。
TDD = TFD +リファクタリング。
TFDを行うときは、リファクタリングを適用して、コードをより汎用的で堅牢なものにします。
歴史的に正しい：テストファーストプログラミングとテスト駆動開発は、改良された名前で同じことを意味します
テストファーストプログラミングとテスト駆動開発を普及させたソフトウェア開発プロセスであるXP（エクストリームプログラミング））のコンテキストでは、テストファーストプログラミングはテスト駆動開発に名前が変更されました。次に、テストを書くことが最初にソフトウェアアーキテクチャとソフトウェアシステムの設計に非常に良い影響を与えるという認識に続くテスト駆動設計。
アーキテクチャと設計に対するこの影響は、多かれ少なかれ驚くべき同義語の結果です。
- テスト可能
- 分離
- 再利用可能
- 独立して展開可能
- 独立して開発可能
- 独立して合理的
ソフトウェアエンティティは、分離されている場合にのみ、簡単に再利用、テスト、独立して展開、独立して開発、または個別に推論することができます。実際の実装前にテストを作成することは、継続的な分離を確実にするためのほぼ完全な方法です。
このソフトウェアの設計とアーキテクチャへの影響は、他の肯定的な効果に加えて非常に重要になったため、作成者は、テストファーストプログラミングからテスト駆動開発に名前を変更する価値があると感じました。
テスト駆動開発という名前は、テストファーストプログラミングよりもメソッドの全体的な側面を強調するため、受け入れと適切な理解の観点からメソッドのマーケティングを促進するのにも役立ちます。
歴史的に正しくはないが有用
歴史的には正しくありませんが、次の区別が非常に役立ちます。
テストファーストプログラミング…
…テスト対象のコードのテストがテスト対象のコードの前に記述される方法です。
テスト駆動開発…
…Robert C. Martinが記述したテスト駆動開発の3つの法則に従うテストファーストプログラミングの特定のサブセット：
- 失敗する単体テストを最初に作成するまで、製品コードを作成することはできません。
- 失敗するのに十分なだけの単体テストを書くことはできません。コンパイルしないと失敗します。
- 現在失敗している単体テストに合格するのに十分な数を超える本番コードを作成することはできません。 — Robert C. Martin、 テスト駆動開発の3つの法則
これらの3つのルールに従うと、いわゆるRed-Green-Refactorサイクルが実行されます。 1.失敗したテストを作成します。 2.あなたはそれを通過させます。 3.合格したので、次の失敗するテストを作成する前に、容赦なくリファクタリングできます。
安全にリファクタリングするにはテストが必要であることに注意してください。リファクタリングとは、重要な動作を変更せずにソースコードの構造を変更することを意味します。しかし、重要な行動を誤って変更していないことをどうやって知るのでしょうか。重要な行動を定義するものは何ですか？これは、テストが役立つ多くのことの1つです。
ところで、テストがリファクタリングの邪魔になる場合は、テストのレベルが低すぎ、結合が緊密であり、モックを使いすぎている可能性があります。
エクストリームプログラミングにおけるその他の興味深い名前の変更
- 継続的インテグレーション->継続的デリバリー->継続的デプロイ;厳密に言えば、それらは異なる意味を持っていますが、XPの精神では、それは最初から継続的な展開を意味し、人々がバンドワゴンに飛び乗ったとき、統合が文字どおりに行われすぎて、人々が完了する前に停止したことがわかりました。
- 継続的なリファクタリング->継続的な設計の改善;リファクタリングはそれ自体が目的を果たすための手段ではなく、より高い目的に従っています。
- 週40時間->持続可能なペース（都市の伝説：この名前変更はフランスのソフトウェア開発者による抗議の後に起こりました。）
それらはまったく同じものです。どちらも最初にテストを記述し、次にテストに合格するコードを記述します。
TDD（テスト駆動開発）はテストファースト開発/プログラミングですが、TDDは（コードの後でも）永続的で反復可能な単体テストを作成することを意味するのを見たり聞いたりしましたが、実際には、テストがコードの前に書かれていることを意味します。
Test Driven Development：By Exampleで、作者Kent Beckは、「最初にテストする」（TF）がルールであると明確に述べています。したがって、TFはTDDを支配する原則です。後者はプロセスです。