TDDが機能する理由 [閉まっている]
最近、テスト駆動開発（TDD）が大きくなっています。プログラマーSEやその他の会場で、さまざまな問題の解決策として推奨されることがよくあります。なぜ機能するのだろうか。 エンジニアリングの観点から見ると、2つの理由で困惑しています。 「書き込みテスト+合格するまでリファクタリングする」アプローチは、信じられないほどアンチエンジニアリングに見えます。たとえば、土木技師が橋の建設にそのアプローチを使用したり、車の車の設計者を使用すると、非常に高いコストで橋や車の形状を変更することになり、その結果、よく考え抜かれたアーキテクチャのないパッチアップされた混乱になります。「リファクタリングまでのパス」ガイドラインは、多くの場合、アーキテクチャ設計を忘れ、テストに準拠するために必要なことをすべて実行することを義務付けられています。つまり、ユーザーではなくテストが要件を設定します。このような状況で、結果の良い「虚偽」、つまり正しいだけでなく、拡張性、堅牢性、使いやすさ、信頼性、安全性、安全性などの最終結果をどのように保証できますか？これは、アーキテクチャが通常行うことです。 テストでは、システムが機能することを保証できません。そうでないことを示すだけです。言い換えれば、テストは、テストに失敗した場合にシステムに欠陥があることを示しますが、すべてのテストに合格したシステムは、テストに失敗したシステムより安全ではありません。ここでは、テスト範囲、テスト品質、およびその他の要因が重要です。「すべてがグリーン」な結果が多くの人々にもたらす誤った安全感情は、民間および航空宇宙産業では非常に危険であると報告されています。テスト戦略として」。多くの場合、テスト戦略はチェックされません。または、誰がテストをテストしますか？ 要約すると、私は「テスト」ビットよりもTDDの「ドリブン」ビットに関心があります。テストはまったく問題ありません。私が得られないのは、それを行うことで設計を推進することです。 ソフトウェアエンジニアリングのTDDが優れた実践である理由と、ソフトウェアの場合に上記で説明した問題が関連性がない（または関連性が十分でない）理由を含む回答をご覧ください。ありがとうございました。