アプリケーションを実際にテストすることで得られる本当のメリットですかTDD
、それともテスト可能なアプリケーションを作成することでもたらされるメリットですか? 私が質問するのは、会話が全体的な福利厚生パッケージではなく、テストを中心に展開することが多すぎると感じているからです。
6 に答える
TDD は、ソフトウェアの設計に役立ちます。テストが設計になります。最初にテストを作成することで、消費者の観点からコードを考え、よりユーザーフレンドリーでコンパクトなソフトウェア設計を作成できます。
また、TDD を適用することで、通常、テスト モックとスタブを提供できる方法でコードを記述することになります。これにより、ソフトウェアの結合が少なくなり、長期にわたる変更と保守が容易になります。
したがって、TDD に関する話の多くはテストに関するものだと思いますが、そうすることで、品質 (カバレッジ)、柔軟性 (デカップリング)、より良い設計 (API の消費者として考えてください) など、他の大きな利点が得られます。
本当の改善点は、設計と実装について真剣に考えるよう強制する良い方法だということです。次に、テストの準備とコードの記述が完了すると、予期しない問題の解決策がより簡単に見つかります。
よく例えると、私によくあることです。フォーラムや IRC チャンネルに質問を投稿するときは、問題がよく書かれていて、十分に説明されているのが好きです。問題の完全な説明により、魔法のように解決策が表示されます。
TDD の本当の利点は、既存の機能が壊れているかどうかを心配することなく、アプリケーションを変更/リファクタリング/強化できることです。単体テストを作成すると、コードが疎結合になり、アーキテクチャが向上する傾向があるという事実は、必ずしも TDD のポイントではありませんが、一方を他方なしで実現するのは難しいと思います。
カバー率の高い単体テストがなければ、TDD の利点を実際に体験することはできません。そのためには、テスト可能なコードを作成する必要があります。そのため、この 2 つを組み合わせて使用したり、代わりに使用したりすることがよくあります。
Michael Feathersは、これに関する洞察に満ちたブログ投稿「ユニットテストの背後にある欠陥のある理論」を公開しています。真剣に、それを読んでください。オチは
これらの技術はすべて、品質を向上させることが示されています。そして、よく見ると、その理由がわかります。それらはすべて、コードを熟考するように強制します。
ただし、コンテキストについては投稿全体を読む必要があります。
自動化されたテストは、複数のバージョンを出荷する製品を開発している場合に、時間の節約と自信の向上に役立ちます。自動テストでは、バージョン間で何も壊れていないことがわかります。これは、製品がアドオンを作成できるものである場合に特に役立ちます。バージョン間でアドオンを壊したくない場合です。
TDD を使用すると、開発中に優れた一連のテストを取得できます。TDD がなければ、これらのテストを作成することははるかに困難です。
自動化されたテストは、人間が機械の仕事をするのを防ぎます。
テスト駆動開発は、自動テストの量を最大化します。
もちろん、ある時点を超えて、人間はまだ必要です。そのポイントを超えてTDDを適用しようとすると、収穫逓減に達します。