TDDを使用した圧倒的なYES（およびいくつかの例外を含む）
議論の余地はありますが、この質問に「いいえ」と答えた人は誰でもTDDの基本的な概念を欠いていると主張します。
私にとって、TDDに従うと答えはイエスです。そうでない場合は、もっともな答えはありません。
TDDのDDD
TDDは、主に3つの利点があると言われています。
- 防衛
- コードが確実に変更される可能性がありますが、動作は変更されません。
- これにより、リファクタリングの非常に重要なプラクティスが可能になります。
- このTDDを獲得するかどうか。
- 設計
- あなたは指定し、それが振る舞うべきか、何をすべきか何か実装する前にそれを。
- これは、多くの場合、より多くの情報に基づいた実装の決定を意味します。
- ドキュメンテーション
- テストスイートは、仕様（要件）のドキュメントとして機能する必要があります。
- そのような目的でテストを使用するということは、ドキュメントと実装が常に一貫した状態にあることを意味します。一方への変更は、他方への変更を意味します。要件とデザインを別々のワードドキュメントに保持することと比較してください。
実装から責任を分離
プログラマーとして、属性を重要なものと考え、ゲッターとセッターを何らかのオーバーヘッドと考えるのは非常に魅力的です。
しかし、属性は実装の詳細であり、セッターとゲッターは実際にプログラムを機能させる契約上のインターフェースです。
オブジェクトがすべきことを綴ることははるかに重要です：
クライアントが状態を変更できるようにする
そして
クライアントがその状態を照会できるようにする
次に、この状態が実際に保存される方法（属性が最も一般的ですが、唯一の方法ではありません）。
などのテスト
(The Painter class) should store the provided colour
TDD のドキュメント部分にとって重要です。
最終的な実装が些細な（属性）であり、防御の利点をもたらさないという事実は、テストを作成するときに知らないはずです。
往復エンジニアリングの欠如...
システム開発の世界における主要な問題の1つは、ラウンドトリップエンジニアリング1の欠如です。 システムの開発プロセスはばらばらのサブプロセスに断片化され、その成果物（ドキュメント、コード）はしばしば矛盾しています。
1 Brodie、Michael L.「ジョンミロポロス：概念モデリングの種を縫う」概念モデリング：基礎とアプリケーション。スプリンガーベルリンハイデルベルク、2009年1-9。
...そしてTDDがそれをどのように解決するか
システムとそのコードの仕様が常に一貫していることを保証するのは、TDD のドキュメント部分です。
最初に設計し、後で実装する
TDD内では、失敗した受け入れテストを最初に記述し、次に合格するコードを記述します。
上位レベルのBDD内で、最初にシナリオを作成し、次にそれらを通過させます。
セッターとゲッターを除外する必要があるのはなぜですか？
理論的には、TDD内で1人がテストを記述し、もう1人がテストをパスするコードを実装することは完全に可能です。
自問してください：
クラスのテストを書いている人がゲッターとセッターに言及する必要があります。
ゲッターとセッターはクラスへのパブリックインターフェイスであるため、答えは明らかにyesであるか、オブジェクトの状態を設定または照会する方法はありません。
明らかに、最初にコードを記述した場合、答えはそれほど明確ではないかもしれません。
例外
このルールにはいくつかの明らかな例外があります-実装の詳細は明確であり、明らかにシステムの設計の一部ではない関数です。
たとえば、ローカルメソッド 'B（）'：
function A() {
// B() will be called here
function B() {
...
}
}
またはsquare()ここのプライベート関数：
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
またはpublic、システムコンポーネントの設計でスペルを必要とするインターフェイスの一部ではないその他の機能。