これをすべて使用する方法は？
いい質問です。 TDDは、現在のタスクの境界を明確に定義し、問題に関連する小さな詳細を同時に処理する簡単な方法を提供し、コードからの迅速なフィードバックを提供して、ソリューションがどれだけ成功したかを伝えるという事実に焦点を当てました。 この技術を研究する際の困難を克服するのに役立つのはこれらの事実です。
書くテストは何ですか？
最も単純な（正確ではあるが）答えは、クラスを評価してさらに設計することを可能にするテストを行うことです。 しかし、この答えは初心者には向いていないため、詳細を掘り下げる必要があります。
私が個人的にTDDを勉強するときに苦労したのは、単純な例から実際のプロジェクトでのTDDの使用への移行でした。 階層の下位クラスのテストを選択すると、結果のコードをプロジェクトに挿入するのが困難になりました。 ここでの問題は、私がテストを本当に必要なものを見つける方法として考えていなかったことです。 そして、問題の解決策を説明するテストを使用した場合にのみ、本当に便利な抽象化が得られました。 秘Theは、現在の問題の知識をカプセル化するテストを作成することです。
より顕著なケースを見てみましょう。 完全に新しいプロジェクトがあるとします。 そのため、どのクラスが必要かさえわかりません。 クラスがまったくないときに、TDDを使用してクラスの将来の構造について何かを学ぶ方法は？ 開発した機能（またはシナリオ）を説明するテストを作成します。 単体テストではなく、受け入れられます。 TDDが単体テストのみに基づいていることはどこにも書かれていませんが、ほとんどの新参者はプロセスがそれらに基づいていると考えており、これからさらに誤解が続きます。 そのため、このアプローチを使用すると、アプリケーションの基本的なスケルトンを作成できます。これにより、さらに発展し、肉体を成長させることができます。 テストにより、必要な機能を管理されたテスト済みの抽象概念にどの程度うまく分割できたかを評価できます。 さらに、システムへの優れたインターフェイスが得られます。これは、将来的に統合テストを作成するときに役立ちます。 この本は優れた例のソースです（リンクは、TestsがガイドするGrowing Object-Oriented Softwareという書籍で、いわゆるLondon School of TDDに捧げられています。
受け入れテストを通じて機能の基本的な動作を決定したら、テストに必要なインフラストラクチャ（ビルド、継続的統合）を作成し、より具体的なテストに進んでアプリケーションの内部クラスを強調表示します。 おそらくこれは必要ないでしょう-受け入れテストで示された方向は機能を実装するのに十分でしょう。
しかし、最初にテストを作成せずにコードを書いただけです！
簡単です。 TDDはコードフィードバックを提供します。 必要なものがすでにわかっている場合（たとえば、完成したアーキテクチャに小さなパーツを追加するのが仕事の場合）、設計を担当するTDDの部分はあまりメリットがありません。 ここでの事前記述テストの唯一の利点は、最初にテストが機能しないことを確認できることです。 これは、テスト自体をテストする方法です。 この場合、「最初のテスト」アプローチは、設計ではなく、テストでカバーされるコードを作成するための手法です。
未知数が少ないほど、それらを見つけるために必要なテストが少なくなり、移動できるステップが大きくなります。
ここでも-MVVMパターンを使用して、予備テストなしでビューを作成しました！
TDDは現在のタスクを制限するだけでなく、そのソリューションをどれだけうまく理解する機会を提供するかを既に学びました。 もちろん、TDDは、最初と2番目の両方を取得する唯一の方法からはほど遠いです。 プレゼンテーションテクノロジー（WPF、MVCフレームワーク、GTK、WebFormsなど）自体は、UIとの相互作用に関してコードに大きな制限を課します。
MVVMなどのプレゼンテーションハイライトパターンを使用する場合、ViewModelに必要なプロパティとコマンドをテストなしで定義できます。 選択されたインターフェイス構築技術、および顧客とのディスカッション中に作成された外部デザイン（これは、迅速なフィードバックを提供するツールでもあります）によって制限されます。
したがって、TDDが問題を制限し、ソリューションの推定値を取得する唯一の方法ではありません。 実際の条件が存在する場合、それらを無視して人為的な条件を発明するべきではありません。
注：TDDの原則に従ってプレゼンテーションパターンを再作成しようとすると、問題が発生しました。テストのみを使用して、MVP、MVVMなどを取得するにはどうすればよいですか。 これは、一方では絶対に本物のUIツールがあり、他方では想像力とテストだけがあるという事実のために、難しいと思います。 テストには従わないが、同様に重要な情報源である要因があります。 誰かがTDDのみを使用して純粋なプレゼンテーション分離パターンを取得できた場合は、お知らせください。
私は立ち往生しています！ テストで立ち往生し、何をすべきかわからない...
これは何度も私に起こったので、それについて話すのは恥ずかしいです。 リファクタリング中に表示されるものを含むコードの各行のテストを考え出すと、最終的には意味のない抽象化の迷路になってしまいました。 TDDは思考に代わるものではないことを忘れないでください。あなたはまだきれいなコードを書くことができる必要があります！
プロセスで必要な情報が提供されない場合は、戻って別の方法で試してください。 同僚とアイデアを話し合う。 より高いレベルの抽象化のテストカバレッジを使用して作業してみてください。 さまざまなアプローチを試してください-理論的に最良の1つを事前に特定するよりも、実際に3つの異なるソリューションを試す方が簡単な場合がよくあります。 TDDは良い方法ですが、問題を制限して解決策を見つける唯一の方法ではありません。 問題を解決するために今すぐ必要なことを行ってください。ただし、戻って停止する理由を後で理解することを忘れないでください。
注：TDDを使用して問題を解決できなかった場合は、他のことを試みる前にこのことを書き留めてください。 このタスクがTDDを使用して原則的に解決不可能であったかどうか、または単に十分な知識を持っていなかったかどうかを理解することが重要です。 早くあきらめると違いを理解できません。 個人的には、この原則に従うことで、濡れ、IoCコンテナー、契約、BDDなどのようなものを発見することができました。 （そして、私はまだ知識のギャップの完全な欠如からは程遠い）。
TDD？ BDD？ ATDD？ 正確に何が必要ですか？
TDDの使用は、各タスク（および各開発者）に固有であることに気付くかもしれません。 さまざまなタスクにより、さまざまな設計上の問題が発生し、さまざまな種類のフィードバックが必要になります。 つまり、TDDをさまざまな方法で使用して、開発されたコードのさまざまな推定値を取得し、それらをアーキテクチャの開発に使用する必要があります。 これらの方法は、「上から下」または「下から上」です。 受け入れテストに主に頼ることができます。 場合によっては、多数の単体テストを使用した方が良い場合があります。 一部の問題は、実際の外部データベースまたはサービスを使用して、エッジツーエッジテストを使用して十分に解決されます（このアプローチには独自の微妙さがありますが、必要なフィードバックを提供し、アーキテクチャの開発を保証する場合は、それを使用します）。
一般的に、真の答えはありません。 主な目標は、現在作業中のコードからフィードバックを得ることです。
おわりに
TDDプロセスの指示は単純ですが、技術自体はそうではありません。 指示は、開始時に最小限の支援のみを提供しますが、TDDをめぐる誇大広告は完全に非現実的な期待を生み出します。
この問題を解決するには、TDDがどのように機能するかを理解し、アルゴリズムの背後にある考え方を確認します。 TDDは実際にはタスクを制限し、「次のテストはどうなるか」という抽象的な質問で設計プロセスをカプセル化し、研究結果を迅速に評価する機能を提供するツールであることがわかります。 基本的に、TDDは、アプリケーション設計を熟考し、繰り返し開発するための優れた方法を提供します。
これを理解したら、意図的にTDDを使用して開発コードからフィードバックを取得し、この情報を使用して設計上の問題を解決できます。 単体テストに限定されず、テスト抽象化のレベルを絶えず切り替えます（TDDを使用したデモ例にはありません）。 また、UIブランチフレームワークやデータストレージテクノロジなど、コードからフィードバックを取得する他の方法があるTDDを使用しなくても簡単に実行できます。
TTDルールを適用することが不可能な場合でも、絶望に陥ることはありません。なぜなら、この手法は単なる設計ツールであり、新しい問題を解決する前に埋めなければならない知識のギャップや経験不足が常にあるからです。 。 TDDが知識不足の優れた指標であるという事実は、現時点で彼らの供給を補充する機会を提供します。 これは至福の忘却よりもはるかに優れており、最終的にはプロジェクトの完了期限に失敗するか、さらに悪いことに、同じ間違いを何度も繰り返すことになります。
設計は常に困難です。 TDDを使用すると、設計に集中し、設計を改善する方法を理解できます。
これらの考えがTDDの別の視点を開き、このテクニックの学習プロセスを容易にすることを願っています。 TDDは努力する価値があります。 頑張って！