TDDが機能する理由 [閉まっている]

最近、テスト駆動開発（TDD）が大きくなっています。プログラマーSEやその他の会場で、さまざまな問題の解決策として推奨されることがよくあります。なぜ機能するのだろうか。

エンジニアリングの観点から見ると、2つの理由で困惑しています。

1. 「書き込みテスト+合格するまでリファクタリングする」アプローチは、信じられないほどアンチエンジニアリングに見えます。たとえば、土木技師が橋の建設にそのアプローチを使用したり、車の車の設計者を使用すると、非常に高いコストで橋や車の形状を変更することになり、その結果、よく考え抜かれたアーキテクチャのないパッチアップされた混乱になります。「リファクタリングまでのパス」ガイドラインは、多くの場合、アーキテクチャ設計を忘れ、テストに準拠するために必要なことをすべて実行することを義務付けられています。つまり、ユーザーではなくテストが要件を設定します。このような状況で、結果の良い「虚偽」、つまり正しいだけでなく、拡張性、堅牢性、使いやすさ、信頼性、安全性、安全性などの最終結果をどのように保証できますか？これは、アーキテクチャが通常行うことです。
2. テストでは、システムが機能することを保証できません。そうでないことを示すだけです。言い換えれば、テストは、テストに失敗した場合にシステムに欠陥があることを示しますが、すべてのテストに合格したシステムは、テストに失敗したシステムより安全ではありません。ここでは、テスト範囲、テスト品質、およびその他の要因が重要です。「すべてがグリーン」な結果が多くの人々にもたらす誤った安全感情は、民間および航空宇宙産業では非常に危険であると報告されています。テスト戦略として」。多くの場合、テスト戦略はチェックされません。または、誰がテストをテストしますか？

要約すると、私は「テスト」ビットよりもTDDの「ドリブン」ビットに関心があります。テストはまったく問題ありません。私が得られないのは、それを行うことで設計を推進することです。

ソフトウェアエンジニアリングのTDDが優れた実践である理由と、ソフトウェアの場合に上記で説明した問題が関連性がない（または関連性が十分でない）理由を含む回答をご覧ください。ありがとうございました。

ここに誤解があると思います。ソフトウェア設計では、設計は製品に非常に近いものです。土木建築では、設計は実際の製品から切り離されます。設計を保持する設計図があり、最終製品に具体化され、それらは膨大な時間と労力によって分離されます。

TDDは設計をテストしています。しかし、すべての車のデザインと建物のデザインもテストされています。建設技術は最初に計算され、次に小規模でテストされ、次に大規模でテストされてから実際の建物に配置されます。たとえば、Hビームと負荷を発明したとき、実際に最初のブリッジを構築する前に、これが試行され、再試行されたことを確認してください。

車の設計も、プロトタイプを設計することによってテストされます。そして、はい、確かに、正しくないものを期待に応えるまで調整することによってテストされます。ただし、このプロセスの一部は遅くなります。なぜなら、あなたが言ったように、製品をいじることができないからです。しかし、車のすべての再設計は、以前のものから学んだ経験に基づいており、すべての建物には、スペース、光、断熱、強度などの重要性に関する約3千年の基礎があります。そして新しいもののための再設計。

また、部品がテストされます。おそらくソフトウェアとまったく同じスタイルではありませんが、通常、機械部品（ホイール、イグナイター、ケーブル）を測定し、サイズが正しいこと、異常が見られないことなどを知るためにストレスをかけます。測定し、レンガをタップして壊れたものを見つけます。実際に何らかの構成でテストしたり、大規模なグループの限定表現を描画して実際にテストしたりします。

これらはすべて、TDDを使用して配置できます。

実際、テストは保証ではありません。プログラムがクラッシュし、車が故障し、風が吹くと建物が面白いことを始めます。しかし...「安全性」はブール問題ではありません。すべてを含めることができない場合でも、50％だけをカバーするよりも、99％の不測の事態をカバーできる方が優れています。テストせずに鋼を見つけることはうまく定まらず、壊れやすく、メイン構造を立てたばかりのハンマーの最初の叩きで壊れますが、お金の無駄です。建物を傷つける可能性のある他の懸念があるとしても、簡単に予防できる欠陥が設計を破壊することを許さないほど愚かではありません。

TDDの実践に関しては、それはバランスの問題です。1つの方法で実行するコスト（たとえば、テストせずに後でピースを拾う）と、別の方法で実行するコスト。それは常にバランスです。しかし、他の設計プロセスにはテストとTDDが存在しないとは思わないでください。

IMO、TDDのサクセスストーリーのほとんどは偽物であり、マーケティング目的のためだけです。成功はほとんどないかもしれませんが、小さなアプリケーションに限られます。私は、TDDの原則が使用されている大きなシルバーライトアプリケーションに取り組んでいます。アプリケーションには数百のテストがありますが、まだ安定していません。複雑なユーザーインタラクションのため、アプリケーションのいくつかの部分はテストできません。多くのモックと理解しにくいコードを使用した結果のテスト。

最初にTDDを試したとき、それはすべて良いようです。私はたくさんのテストを書いて、単体テストには難しい部分をモックアウトすることができました。かなりの量のコードがあり、インターフェースの変更が必要になると、ユーザーはめちゃくちゃになります。多くのテストを修正する必要があり、コードの実際の変更よりも多くのテストを書き換えます。

Peter Norvigは、Coders At WorkブックでTDDについての彼の見解を説明しています。

Seibel：テストを使用して設計を推進するというアイデアはどうですか？

Norvig：私はテストを設計の方法としてではなく、エラーを修正する方法としてより見ています。「最初にやるべきことは、最後に正しい答えが得られるというテストを書くことです」と言う極端なアプローチです。次に、それを実行して失敗したことを確認し、「私は何をしますか」と言います。次は必要ですか？」—それは私にとって何かを設計する正しい方法とは思えません。解決策が事前に定められているほど単純な場合にのみ意味があるように思えます。最初にそれについて考える必要があると思います。あなたは言わなければならない、「ピースは何ですか？そして、それらの一部が何であるかを知るまで、どうやってピースのテストを書くことができますか？」そして、それができたら、それらの各ピースのテストを行い、それらが互いにどのように相互作用するかをよく理解することは良い規律です境界ケースなど。それらにはすべてテストが必要です。しかし、「このテストは失敗しました」と言って、設計全体を推進するとは思わない。

テスト駆動設計は、次の理由で機能します。

これは、実行可能な形式の仕様です。

これは、テストケースから確認できることを意味します。

1. その期待される結果は、テストケースに右あるようにコードが呼び出されている仕様をフル充填します。目視検査（テストケースに合格することを期待）は、すぐに「ああ、このテストでは、この状況でinvoiceCompanyを呼び出すと、その結果が得られることを確認します」と言うことができます。
2. どのようにコードを呼び出す必要があります。テストを行うために必要な実際の手順は、外部の足場なしで直接指定されます（データベースはモックアウトされますなど）。

最初に外部からビューを作成します。

多くの場合、コードは最初に問題を解決する方法で作成され、次に作成したコードがどのように呼び出されるかを考えます。「フラグを追加する」などの方が簡単なことが多いため、これは頻繁に厄介なインターフェイスを提供します。これにより、コードは呼び出し元のインターフェイスに従って作成され、逆の方法ではないため、モジュール性が向上します。

これにより、通常、コードも簡潔になり、説明の少ないドキュメントが必要になります。

早く終わります

実行可能な形式の仕様を持っているので、完全なテストスイートに合格すると完了です。物事をより詳細なレベルで明確にすると、さらにテストを追加できますが、基本的な原則として、進捗状況と完了したことを非常に明確で目に見える形で示すことができます。

これは、作業が必要かどうかを判断できることを意味します（テストに合格するのに役立ちます）。

それらについて熟考している人にとっては、次のライブラリルーチンにTDDを使用することをお勧めします。実行可能な仕様をゆっくり設定し、コードがテストに合格するようにします。完了すると、ライブラリの呼び出し方法を確認する必要があるすべての人が実行可能な仕様を利用できます。

最近の研究

「ケーススタディの結果は、TDDプラクティスを使用しなかった同様のプロジェクトと比較して、4つの製品のリリース前の欠陥密度が40％から90％減少したことを示しています。 TDDを採用した後の初期開発時間。」〜4 つの産業チームの結果と経験

ソフトウェアを作成するプロセスは、コードを記述するプロセスではありません。最初に「広範囲」計画なしにソフトウェアプロジェクトを開始することはできません。川の2つの岸を橋渡しするプロジェクトのように、最初にそのような計画が必要です。

TDDアプローチは（ほとんど）単体テストに関連しています-少なくともそれは人々がそれについて考える傾向があります-それはソフトウェアコードの最も低レベルのビットを作成しています。すべての機能と動作が既に定義されていて、実際に何を達成したいかがわかっている場合。

構造工学では、次のようになります。

「これらの2つの金属片を互いに接続しており、接続はxのオーダーでせん断力を維持する必要があります。これを行うのに最適な接続方法をテストしましょう」

ソフトウェアが全体として機能するかどうかをテストするために、ユーザビリティテスト、統合テスト、受け入れテストなど、他の種類のテストを設計します。これらも、コードの記述に関する実際の作業を開始する前に定義する必要があり、ユニットテストが緑になった後に実行されます。

Vモデルを参照してください：http : //en.wikipedia.org/wiki/V-Model_%28software_development%29

ブリッジに対してどのように機能するかを見てみましょう。

1. 地方自治体は、橋梁建設会社に次のように述べています。「これら2つのポイントを接続するには橋が必要です。橋は1時間あたりnのトラフィックを許可し、2012年12月21日まで準備ができている必要があります」-これは受入テスト：会社は、テストに合格できない場合、全額（または任意の）お金を受け取りません。

2. 会社の管理がプロジェクトのスケジュールを決定します。彼らは作業チームを設定し、各チームの目標を設定します。チームがこれらの目標を達成しない場合-ブリッジは時間通りに構築されません。ただし、ここにはある程度の柔軟性があります。チームの1つに問題がある場合、会社は要件を変更する、下請業者を変更する、より多くの人を雇うなどして、プロジェクト全体がポイント＃1で設定された目標をまだ満たすようにすることでそれを相殺できます。

3. 特定のブリッジコンポーネントの設計を担当するチーム内では、上記の例のようになります。ブリッジの構築に関する膨大な知識を持っているため、ソリューションが明らかな場合があります（ソフトウェア開発で十分にテストされたライブラリを使用するようなものです-宣伝どおりに機能すると仮定します）。いくつかのデザインを作成してテストし、最適なデザインを選択する必要がある場合があります。それでも、コンポーネントをテストする基準は事前にわかっています。

私の考えでは、TDDが機能するのは、

• 仕様や要件ドキュメントで通常カバーされていない精度レベルで実装を決定する前に、ユニットに何をさせるかを強制的に定義します
• テストと本番の両方のシナリオで使用する必要があるため、コードを本質的に再利用可能にします
• より小さなデザインでコードを書いて、より良い設計につながる傾向があるチャンクをテストすることをお勧めします

具体的には、あなたがあげるポイントについて

• コードは、レンガやスチールよりも順応性が高いため、修正するのが安価です。動作が変更されていないことを確認するテストがある場合は、さらに安価です
• TDDは設計を行わない言い訳ではありません。高レベルのアーキテクチャは一般的に推奨されますが、あまり詳細ではありません。Big Up Front Designは推奨されませんが、十分な設計を行うことをお勧めします
• TDDはシステムが動作することを保証することはできませんが、さもなければ見逃されることになる多くの小さな間違いを防ぐことができます。また、一般的に、より良いファクタリングされたコードを推奨するため、多くの場合、理解しやすく、バグが発生しにくい

TL; DR

プログラミングはまだ設計作業であり、構築ではありません。事実の後にユニットテストを書くことは、コードがそれがすることをすることを確認するだけであり、何か有用なことをすることではありません。テストの失敗は、間違いを早期に発見できるため、真の価値があります。

コードは設計

PPPの第7章「ボブおじさん」はこの問題について直接話しています。この章の非常に早い段階で、彼はJack Reevesの優れた記事を参照しています。この記事では、コードは設計であると提案しています（リンクはトピックに関する3つの記事すべてを集めたページに移動します）。

この議論の興味深い点は、建設が非常に高価な活動である他のエンジニアリング分野とは異なり、ソフトウェアの建設が比較的無料であることです（IDEでコンパイルし、ソフトウェアを構築しました）。コードの作成を建設作業ではなく設計作業と見なす場合、赤緑リファクタリングサイクルは基本的に設計の練習です。テストを作成し、それらを満足させるコードを作成し、リファクタリングして新しいコードを既存のシステムに統合するにつれて、設計は進化します。

仕様としてのTDD

TDD用に作成する単体テストは、理解しているとおりに仕様を直接翻訳したものです。最小限の仕様を満たすコードを書くことにより（テストを緑にする）、あなたが書いたコードはすべて特定の目的のためにそこにあります。その目的が達成されたかどうかは、反復可能なテストによって検証されます。

機能へのテストの書き込み

単体テストでよくある間違いは、コードの後に​​テストを書くときに発生し、最終的にはコードがその機能を果たすかどうかをテストします。つまり、このようなテストが表示されます

public class PersonTest:Test
{
   [Test]
   TestNameProperty()
   {
      var person=new Person();
      person.Name="John Doe";
      Assert.AreEqual("John Doe", person.Name);
   }
}

このコードは役に立つかもしれませんが（誰かが単純なプロパティでわいせつなことをしていないことを確認してください）。仕様の検証には役立ちません。そして、あなたが言ったように、これらの種類のテストを書くことはこれまでのところあなただけを取ります。

緑は良いのですが、価値は赤 にありますTDDで予期せぬテストが失敗したとき、真の「あは」の瞬間がありました。私が構築しているフレームワークに対して行った一連のテストがありました。新しい機能を追加して、テストを作成しました。次に、テストに合格するコードを作成しました。コンパイル、テスト...新しいテストで緑色になりました。しかし、私が赤くなるとは思わなかった別のテストでも赤になりました。

失敗を見て、私は安placeのため息をつきました。なぜなら、そのテストを実施していなければ、かなり長い間そのバグを捕らえたのではないかと思うからです。そして、それは非常に厄介なバグでした。幸いなことに、私はテストを受け、バグを修正するために必要なことを正確に教えてくれました。テストがなければ、私はシステムを構築し続け（そのコードに依存する他のモジュールにバグが感染する）、バグが発見されるまでに、それを適切に修正することは大きなタスクでした。

TDDの真の利点は、無謀な放棄で変更を加えることができることです。それはプログラミングの安全策のようなものです。空中ブランコのアーティストがミスをして転倒したらどうなるか考えてみてください。ネットでは、それは恥ずかしい間違いです。なしでは、それは悲劇です。同様に、TDDを使用すると、骨の折れる間違いをプロジェクトの惨事に変えることを防ぐことができます。

テスト駆動型開発、またはテスト駆動型設計（異なる）を提唱する人はいません。テストはアプリケーションを証明します。だから、それをただのストローマンと呼んで完了させましょう。

テストが時間と労力の浪費であると言うTDDに嫌悪感を抱いている人や感心していない人はいません。テストはアプリケーションを証明しませんが、エラーを見つけるのに非常に役立ちます。

これら2つのことから、どちらの側も、ソフトウェアで実際にテストを実行することに関して異なることをしていません。両方ともテストを行っています。両方とも、できるだけ多くのバグを見つけるためのテストに依存しており、両方ともテストを使用して、ソフトウェアプログラムが動作しており、その時点で発見できることを確認します。手掛かりの半分の人がテストなしでソフトウェアを販売することはありません。

したがって、TDDと非TDDの違いは、テストが行​​われているということではありません。違いは、テストを作成するタイミングです。TDDでは、ソフトウェアの前にテストが記述されます。not-TDDテストは、ソフトウェアの後、またはソフトウェアと一緒に作成されます。

後者に関して私が見た問題は、テストでは、目的の結果や仕様よりも記述されているソフトウェアをターゲットにする傾向があるということです。テストチームが開発チームから分離されている場合でも、テストチームはソフトウェアを見て、それで遊んで、それを対象とするテストを書く傾向があります。

プロジェクトの成功を研究する人々によって何度も気づかれていることの1つは、顧客が望むものをレイアウトする頻度、開発者が逃げて何かを書くこと、そして顧客が「完了」と言って戻ってくるときです。それは、顧客が求めたものではなく、完全に完全であることが判明しました。「しかし、すべてのテストに合格します...」

TDDの目標は、この「循環論法」を破り、ソフトウェアそのものではないソフトウェアをテストするテストの基礎を提供することです。テストは、「顧客」が望んでいる動作を対象とするように作成されています。ソフトウェアは、これらのテストに合格するように作成されます。

ただし、TDDはこの問題に対処するためのソリューションの一部です。あなたが行う唯一のステップではありません。あなたがする必要がある他のことは、より多くの顧客フィードバックとより頻繁にあることを確認することです。

しかし、私の経験では、TDDをうまく実装することは非常に困難です。多くの自動化されたテストでは、自動化ソフトウェアを正しく動作させるために何かをする必要があるため、製品が発売される前にテストを作成するのは困難です。また、単体テストに慣れていない開発者にそれを実行させることも困難です。何度も何度もチームの人々にテストを最初に書くように言ってきました。私は実際にそれをやったことがありません。最終的には、時間の制約と政治がすべての努力を破壊し、ユニットテストさえも行わなくなった。もちろん、これにより、必然的に、設計が偶然および厳しく結合されることになり、その結果、たとえ実行したとしても、実装するのに法外なコストがかかることになります。TDDを回避することが、TDDが最終的に開発者に提供するものです。

最初に設計する

TDDは設計をスキップする言い訳ではありません。すぐにコーディングを開始できたにもかかわらず、「アジャイル」な時流に多くのジャンプを見てきました。真のアジャイルにより、ウォーターフォールプロセスに影響を与えた（他の分野の）エンジニアリンググッドプラクティスよりもはるかに高速にコーディングを統計することができます。

しかし、早期にテストする

テストが設計を推進していると言うとき、それは単に、設計フェーズの非常に早い段階で、それが完了するずっと前にテストを使用できることを意味します。このテストを行うと、製品が完成するずっと前に灰色の領域に挑戦し、現実の世界に照らして設計に大きな影響を与えます。これを考慮して設計に戻って調整することを頻繁に強制します。

テストと設計...まったく同じ

私の意見では、TDDは、テストを最後に検証のために行うのではなく、単にデザインの不可欠な部分にするだけです。TDDの使用を開始するにつれて、システムを設計するときにシステムを破壊/破壊する方法の考え方がますます強くなります。個人的には、常に最初にテストを行うとは限りません。確かにインターフェイス上で明白な（ユニット）テストを行いますが、実際の利益は、このデザインが破れる新しい創造的な方法を考えるときに作成する統合テストと仕様テストから得られます。方法を考えるとすぐに、そのためのテストをコーディングし、何が起こるかを確認します。時々、結果に耐えることができます。この場合、メインビルドの一部ではない別のプロジェクトにテストを移動します（失敗し続けるため）。

それでは誰がショーをドライブしますか？

TDDでは、ここでの駆動とは、テストが設計に非常に強く影響するため、実際にテストを実行していると感じることができることを意味します。しかし、それはそれで止まります、そして、ここであなたの懸念を理解しています、それは少し怖いです...誰がショーを運転しますか？

あなたはテストではなく運転しています。テストはそこにあるので、あなたが進んでいくと、あなたが作成したものに対して十分な自信を得ることができ、それにより、それがしっかりした根拠に基づいていることをさらに知ることができます。

テストが固体である限り固体

正確に、したがって、TDDで駆動されます。テストがすべてを推進しているわけではありませんが、システムが設計方法や考え方に大きな影響を与えているため、思考プロセスの大部分をテストに委任し、見返りにしています彼らはあなたのデザインに深い影響を与えます。

ええ、でも、もし橋でそれをやると…

ソフトウェアエンジニアリングは、他のエンジニアリングプラクティスとはまったく異なります。実際、ソフトウェアエンジニアリングには、実際に文学との共通点が多くあります。完成した本を取り、それから4つの章をリッピングし、2つの新しい章を書いてそれらを置き換えることができます。優れたテストとソフトウェアを使用すると、システムの任意の部分をリッピングして別の部分に置き換えることができます。そのためのコストは、そもそもシステムを作成するよりも高くありません。実際、テストを行って設計に十分な影響を与えた場合、最初の段階で作成するよりもはるかに安くなる可能性があります。これは、この置換がテストの対象を破壊しないというある程度の自信があるからです。

そのすっごく良い方法は、なぜそれが常に動作しないのですか？

テストには、構築とはまったく異なる考え方が必要だからです。すべての人が戻ったり戻ったりできるわけではありません。実際、創造を破壊するように心を決められないという理由だけで、適切なテストを構築できない人もいます。これにより、テストの数が少なすぎるか、ターゲットメトリックに到達するのに十分なテストが得られます（コードカバレッジが頭に浮かびます）。彼らは幸せなパステストと例外テストを行いますが、コーナーケースと境界条件については忘れます。

他の人は、設計を部分的にまたはまったく行わないテストに依存するでしょう。それを行う各メンバーは、お互いに統合することです。デザインは何よりもまずコミュニケーションツールであり、私たちがここにいると言うために地面に置いたステーク、これがドアと窓がある場所だと言うスケッチです。これがなければ、あなたは、あなたがそのソフトウェアに何回テストを入れても、運命づけられます。統合とマージは常に苦痛を伴い、最高レベルの抽象化でのテストが不足します。

これらのチームのTDDは、進むべき道ではないかもしれません。

TDDを使用すると、テストが簡単または迅速でないコードを記述しない傾向があります。これは小さなことのように思えるかもしれませんが、リファクタリング、テスト、テストでのバグの再現、修正の検証がどれだけ簡単かということに影響するため、プロジェクトに大きな影響を与える可能性があります。

また、プロジェクトの新しい開発者は、テストでサポートされているコード化されたより優れたコードを使用していると、速度を上げるのが簡単になります。

私はTDDをあまり練習していませんが、これについてはずっと考えてきました。コード品質と後続のTDDの間に（強い？）正の相関があるようです。

1）私の最初の考えは、これは（主に）TDDがコードに「より良い品質」を追加することによるものではなく（そのようなものとして）、TDDが最悪の部分や習慣を取り除くのに役立ち、間接的に品質を向上させることです。

私もそれがテストそのものではないことを提唱う-それはプロセスです書いてこれらのテストを。悪いコードのテストを書くのは難しいですし、逆の場合も同様です。また、プログラミング中にこれを後回しにしておくことで、多くの不正なコードを排除できます。

2）別の観点（これは哲学的になっています）は、マスターの精神的な習慣に従うことです。あなたは彼の「外部の習慣」に従うことによってマスターになることを学ぶことはありません（例えば、長いひげは良いです）、あなたは彼の内部的な考え方を学ばなければなりません、そしてこれは難しいです。そして、どういうわけか（初心者）プログラマーをTDDに従って、マスターの考え方に近い考え方を揃えます。

「書き込みテスト+合格するまでリファクタリングする」アプローチは、信じられないほどアンチエンジニアリングに見えます。

リファクタリングとTDDの両方について誤解しているようです。

コードリファクタリングとは、ソフトウェアの非機能属性の一部を改善するために、外部機能動作を変更せずにコンピュータープログラムのソースコードを変更するプロセスです。

したがって、合格するまでコードをリファクタリングすることはできません。

そして、TDD、特にユニットテスト（他のテストはかなり妥当と思われるため、コアの改善と考えています）は、機能するまでコンポーネントを再設計することではありません。コンポーネントが設計どおりに機能するまで、コンポーネントを設計し、実装に取り​​組みます。

また、それは本当に把握することが重要で、そのユニットテストはおよそテストしている単位を。常にゼロから多くのことを書く傾向があるため、そのようなユニットをテストすることが重要です。土木技師は、使用しているユニットの仕様（さまざまな材料）をすでに知っており、動作することを期待できます。これらは多くの場合ソフトウェアエンジニアには当てはまらない2つのことです。テスト済みの高品質のコンポーネントを使用することを意味するため、ユニットを使用する前にテストすることは非常にプロエンジニアリングです。
土木技師がスタジアムを覆う屋根を作るために新しい繊維ティッシュを使用するというアイデアを持っていた場合、彼はそれをユニットとしてテストすることを期待します。その後、それらが満たされるまでテストと改良を行います。

それがTDDが機能する理由です。テストされたユニットのソフトウェアを構築する場合、それらを一緒に接続し、そうでない場合、テストのカバレッジが良好であると仮定して、グルーコードに問題があると予想できる可能性がはるかに優れています。

編集：
リファクタリングとは、機能に変更がないことを意味します。単体テストを記述する1つのポイントは、リファクタリングによってコードが破損しないことを確認することです。TDDは、リファクタリングに副作用がないことを保証するためのものです。
先ほど言ったように、粒度は正確には定義されていないため、システムではなくユニットをテストするため、粒度は観点の対象ではありません。

TDDは優れたアーキテクチャを促進します。すべてのユニットの仕様を定義および実装する必要があり、実装前にそれらを設計する必要がありますが、これはあなたが考えていることとはまったく反対です。TDDはユニットの作成を指示します。ユニットは個別にテストできるため、完全に分離されます。
TDDは、スパゲッティコードでソフトウェアテストを投げ、パスタがパスするまで攪拌するという意味ではありません。

土木工学とは対照的に、ソフトウェア工学では通常、プロジェクトは常に進化しています。土木工学では、位置Aに橋を建設する必要があります。橋はxトンを運ぶことができ、1時間にn台の車両に十分な幅があります。
ソフトウェアエンジニアリングでは、顧客は基本的に任意の時点（おそらく完成後）で、ダブルデッキブリッジを望み、最寄りの高速道路に接続することを望みます。最近、帆船を使い始めました。
ソフトウェアエンジニアは、設計を変更する必要があります。彼らのデザインに欠陥があるからではなく、それが手口だからです。ソフトウェアが適切に設計されていれば、低レベルのコンポーネントをすべて書き直すことなく、高レベルで再設計できます。

TDDは、個別にテストされ、高度に分離されたコンポーネントを使用してソフトウェアを構築することです。適切に実行されると、要件の変更に対応するのに役立ちます。

TDDは開発プロセスに要件を追加しますが、品質保証の他の方法を禁止しません。確かに、TDDはフォーマル検証と同じセキュリティを提供しませんが、フォーマル検証は非常にコストがかかり、システムレベルで使用することは不可能です。それでも、必要に応じて、両方を組み合わせることができます。

TDDには、システムレベルで実行される単体テスト以外のテストも含まれます。これらは説明しやすいが、実行するのが難しく、測定するのが難しいと思う。また、彼らは非常に妥当です。私は彼らの必要性を絶対に見ていますが、私はそれらをアイデアとして本当に評価していません。

最終的に、実際に問題を解決するツールはありません。ツールは問題の解決を容易にするだけです。あなたは尋ねることができます：ノミはどのように素晴らしい建築で私を助けますか？まっすぐな壁を作るつもりなら、まっすぐなレンガが助けになります。確かに、そのツールをバカに渡せば、彼は最終的に彼の足を叩くでしょうが、それはノミのせいではありません。初心者に誤ったセキュリティを与えるのはTDDの欠陥ではないからです良いテストを書かない人。
結論として、TDDはTDDを使用しないよりもはるかに優れていると言えます。

「ユーザーではなくテストが要件を設定する」という発言が好きではありません。TDDでは単体テストのみを検討していると思いますが、統合テストも対象としています。

ソフトウェアのベースを構成するライブラリのテストとは別に、ユーザーがソフトウェア/ウェブサイト/その他との相互作用をカバーするテストを作成します。これらはユーザーから直接送られてくるものであり、cucumber（http://cukes.info）のようなライブラリーでは、ユーザーが自然言語でテストを自分で書くことさえできます。

また、TDDはコードの柔軟性を促進します。何かのアーキテクチャを永遠に設計することに費やした場合、必要に応じてそれらの変更を後で行うことは非常に困難になります。いくつかのテストを書くことから始め、それらのテストに合格する小さなコードを書きます。テストを追加し、コードを追加します。コードを根本的に変更する必要がある場合でも、テストは有効です。

また、橋や車とは異なり、1つのソフトウェアはその存続期間中に大きな変更を受ける可能性があり、最初にテストを作成せずに複雑なリファクタリングを行うことは、単にトラブルを要求するだけです。

間違った角度から最初のポイントに近づいていると思います。

理論的な観点から、障害点をチェックすることで何かが機能することを証明しています。それが使用される方法です。何かが機能していることを証明できる方法は他にもたくさんありますが、TDDはビット単位のアプローチの単純さにより確立しています。

実際には、これは率直に言って次のように変換されます。次のことに進むことができます（すべての述部を満たすためにTDDを正常に適用した後）。この観点からTDDにアプローチする場合、「テストを書く+パスまでリファクタリングする」ことではなく、これを完了することです。私は今、最も重要なこととして次の機能に完全に焦点を当てています。

これが土木工学にどのように適用されるか考えてください。15万人の観客を収容できるスタジアムを建設しています。スタジアムの構造的健全性が健全であることを証明した後、まず安全性を満足させました。洗面所、フードスタンド、座席など、すぐに重要になる他の問題に焦点を当てることができます...観客の体験をより楽しいものにします。TDDにはさらに多くの要素があるため、これは単純化しすぎていますが、重要なのは、新機能とエキサイティングな機能の両方に焦点を合わせ、同時に整合性を維持する場合、最高の最悪のユーザーエクスペリエンスを実現できないことです。どちらの場合も途中で取得します。つまり、どうやって正確に知ることができますか多くの洗面所があり、150000人のためにどこに配置すればよいですか？私は自分の生涯でスタジアムが崩壊することはめったにありませんでしたが、ハーフタイムの間は非常に多くの機会に並んで待たなければなりませんでした。それは、トイレの問題はほぼ間違いなくより複雑であり、エンジニアが安全に費やす時間が少なくなると、最終的にトイレの問題を解決できる可能性があることを示しています。

あなたの2番目のポイントは無関係です。なぜなら、アブソリュートは愚か者の努力であることにすでに同意しており、ハンクムーディはそれらが存在しないと言っているからです（しかし、そのための参照が見つからないようです）。

ソフトウェアエンジニアリングのTDDは、アプリケーションでのエラー処理と同様に、ログ記録と診断（エラー処理の一部ですが）と同様に、優れた実践です。

TDDは、ソフトウェア開発を試行錯誤のコーディングに減らすためのツールとして使用することはできません。それでも、ほとんどのプログラマーは、ランタイムログをじっと見たり、デバッガーで例外を監視したり、アプリのコーディング/コンパイル/実行で構成される開発フェーズ中に他の失敗/成功の兆候を終日使用します。

TDDは、これらのステップを形式化および自動化して、開発者としての生産性を向上させるための単なる方法です。

1）ソフトウェアエンジニアリングと橋梁建設を比較することはできません。橋梁建設の柔軟性は、ソフトウェアプログラムの設計に匹敵するものではありません。ブリッジの構築は、同じプログラムを損失の多いマシンに何度も書くようなものです。ソフトウェアのようにブリッジを複製して再利用することはできません。各ブリッジは一意であり、製造する必要があります。車や他のデザインにも同じことが言えます。

ソフトウェアエンジニアリングで最も難しいことは、障害を再現することです。ブリッジに障害が発生した場合、通常、障害の原因を特定するのは非常に簡単で、理論的には障害を再現するのは簡単です。コンピュータプログラムが失敗すると、システムが障害状態になったイベントの複雑なチェーンになり、エラーの場所を特定するのが非常に難しくなります。TDDとユニットテストにより、ソフトウェアコンポーネント、ライブラリ、アルゴリズムの堅牢性を簡単にテストできます。

2）システムにストレスをかけずに弱い単体テストと浅いテストケースを使用して、誤った自信を構築することは、単に悪い習慣です。システムのアーキテクチャの品質を無視し、テストを実行するだけでも、もちろん悪いことです。しかし、高層ビルや橋の建設現場で材料を節約し、設計図に従わないために不正をすることは同じくらい悪いことであり、それは常に起こります...

バグがより早く発見され、それらを修正するコストが少ないことを受け入れた場合、それだけでTDDの価値が高まります。

TDDは実際にはテストに関するものではありません。そして、それは確かに良いテストに取って代わるものではありません。それがあなたに与えるものは、よく考えられ、消費者が消費しやすく、後で維持しリファクタリングしやすい設計です。これらのことは、バグの減少と、より優れた、より適応性のあるソフトウェア設計につながります。TDDはまた、仮定を熟考して文書化するのに役立ち、多くの場合、それらの一部が間違っていることを発見します。これらはプロセスの非常に早い段階で見つかります。

また、副次的な利点として、リファクタリングによってソフトウェアの動作（入力および出力）が変更されないことを確認するために実行できるテストの大きなスイートがあります。

簡単に答えます。通常、TDDは、単体テストと同様に間違った方法で見られます。良いテクトークビデオを見た後、最近までユニットテストを理解していませんでした。基本的に、TDDは、次のことを機能させたいと述べているだけです。それらを実装する必要があります。次に、通常の方法で残りのソフトウェアを設計します。

ライブラリを設計する前に、ライブラリのユースケースを書くようなものです。ライブラリのユースケースを変更でき、TDDを使用しない場合があることを除きます（API設計にはTDDを使用しています）。また、さらにテストを追加し、テストが取得する可能性のあるワイルドな入力/使用について考えることをお勧めします。何かを変更した場合、何かを壊したことを知っておく必要があるライブラリやAPIを作成するときに役立ちます。ほとんどの毎日のソフトウェアでは、ユーザーがボタンを押すためのテストケースが必要なのはなぜですか、CSVリストまたは1行に1つのエントリがあるリストを受け入れる必要があるので、気にしません...それは本当に問題ではありませんそれを変更するには、TDDを使用するべきではありません。

構造工学が具体的な場合、ソフトウェアは有機的です。

ブリッジを構築すると、ブリッジのままになり、短期間に他の何かに進化する可能性は低くなります。改善は数か月から数年にわたって行われますが、ソフトウェアのように数時間や数日はかかりません。

単独でテストする場合、通常使用できるフレームワークには2つのタイプがあります。制約のあるフレームワークと制約なし。制約のないフレームワーク（.NET）では、アクセス修飾子に関係なく、すべてをテストして置き換えることができます。すなわち、プライベートおよび保護されたコンポーネントをスタブおよびモックできます。

私が見たプロジェクトのほとんどは、制約のあるフレームワーク（RhinoMocks、NSubstitute、Moq）を使用しています。これらのフレームワークを使用してテストする場合、実行時に依存関係を挿入および置換できるようにアプリケーションを設計する必要があります。これは、疎結合設計が必要であることを意味します。疎結合設計（適切に行われた場合）は、関心事のより良い分離を意味し、これは良いことです。

要約すると、この背後にある考え方は、デザインがテスト可能である場合、疎結合であり、懸念が十分に分離されていると考えています。

ちなみに、私は本当にテスト可能なアプリケーションを見てきましたが、オブジェクト指向の設計の観点からは不十分に書かれています。

TDDが機能する理由

そうではありません。

明確化：自動テストは、テストなしよりも優れています。しかし、私は個人的には、ほとんどの単体テストが無駄であると考えています（つまり、テスト中の実際のコードから明らかなことを言います）、一貫性があり、冗長ではなく、すべての境界ケースをカバーすることは簡単に証明できません（エラーが通常発生する場合） ）。

そして最も重要なこと：優れたソフトウェア設計は、多くのアジャイル/ TDDエバンジェリストによって宣伝されているように、テストから魔法のように外れることはありません。それ以外の場合は、これを証明する査読済み科学研究へのリンク、または少なくともコード変更履歴によってTDDの利点を調査できる可能性のあるオープンソースプロジェクトへの参照を提供してください。