成熟したプロジェクトにテスト駆動開発 (TDD) を導入することは可能ですか?[閉まっている]

Question

• TDD の価値に気づくのが遅すぎたとします。プロジェクトはすでに成熟しており、多くの顧客が使用を開始しています。
• たとえば、使用される自動テストのほとんどが機能/システム テストであり、自動 GUI テストがかなり行われているとします。
• 新しい機能のリクエストと新しいバグレポート (!) があるとします。かなりの開発がまだ続いています。
• 単体テストがまったくないか、ほとんど行われていないビジネス オブジェクトがすでに大量にあることに注意してください。
• それらの間のコラボレーション/関係が多すぎるため、これもより高いレベルの機能/システム テストを通じてのみテストされます。統合テスト自体はありません。
• 多数のテーブル、ビューなどを備えた大規模なデータベースが配置されています。単一のビジネス オブジェクトをインスタンス化するだけでも、すでにかなりのデータベースのラウンド トリップが行われています。

現段階で TDD を導入するにはどうすればよいでしょうか?

嘲笑することが最善策のようです。しかし、ここで行う必要がある嘲笑の量は多すぎるように思えます。既存のもの（BO、データベースなど）で動作するモックシステムのために、精巧なインフラストラクチャを開発する必要があるようです。

ということは、TDD はゼロから始める場合にのみ適切な方法論であるということでしょうか?すでに成熟した製品に TDD を導入するための実現可能な戦略について知りたいと思っています。

Answer 1

複雑なモック インフラストラクチャを作成しても、おそらくコードの問題が隠れてしまうだけでしょう。変更する予定のコード ベースの領域を中心に、テスト データベースを使用した統合テストから始めることをお勧めします。十分なテストを行って、変更を加えても何も壊れないことを確認したら、コードをよりテストしやすくするためにコードのリファクタリングを開始できます。

マイケル・フェザーの素晴らしい本もご覧ください 従来のコードを効果的に使用する, 、レガシー コード ベースに TDD を導入しようと考えている人は必ず読んでください。

Answer 2

既存のアプリケーションに TDD を導入することは完全に実現可能だと思います。実際、私自身も最近導入しました。

TDD の方法で新しい機能をコーディングし、これに対応するために既存のコードを再構築するのが最も簡単です。この方法では、コードの小さなセクションからテストを開始しますが、その影響はコード ベース全体に広がり始めます。

バグがある場合は、それを再現する単体テストを作成し、必要に応じてコードをリファクタリングします (労力が本当に価値がない場合を除く)。

個人的には、既存のシステムにテストを組み込む必要はないと思います。それは、大きなメリットがなければ非常に面倒な作業になる可能性があるからです。

要約すると、小規模から始めれば、プロジェクトはますますテストに感染することになります。

Answer 3

はい、できます。あなたの説明によると、プロジェクトは良好な状態にあります。機能テストの自動化は確実に行われています。いくつかの側面では、単体テストよりもさらに便利です。TDD != 単体テストであることを忘れないでください。これはすべて、短い反復と確実な合格基準が重要です。

既存の承認されたプロジェクトがあると、実際にテストが容易になることを覚えておいてください。動作するアプリケーションが最良の要件仕様です。つまり、紙切れを持って仕事をするだけの人よりも、あなたは有利な立場にあるのです。

TDD を使用して新しい要件やバグ修正に取り組み始めるだけです。方法論の切り替えにはオーバーヘッドが発生することを忘れないでください (クライアントには必ずこのことを認識してください!)。また、おそらく「古き良き方法」に慣れているチーム メンバーからのかなりの抵抗が予想されます。

必要がない限り、古いものには触れないでください。既存のものに影響を与える拡張リクエストがある場合は、追加のセットアップ作業を行うための追加の時間を考慮に入れてください。

個人的には、モックアップに複雑なインフラストラクチャを導入することにはあまり価値がありません。確かに軽量モードで同じ結果を達成する方法はありますが、それは明らかに状況に依存します。

Answer 4

従来のコードのテストに役立つツールの 1 つ (リファクタリングできない/時間がない場合を想定) は、Typemock Isolator です。typemock.com標準反射技術（動的プロキシなど）を使用していないが、代わりにプロファイラーAPIを使用するため、インターフェイスなどを抽出する必要なく、既存のコードに依存関係を注入することができます。これは、sharepoint、HTTPContext、その他の問題のある領域に依存するアプリをテストするために使用されてきました。ぜひご覧ください。（私はその会社で開発者として働いていますが、既存のレガシーコードをリファクタリングすることを強制しない唯一のツールです。時間とお金を節約します）また、より多くのテクニックのために「レガシーコードで効果的に作業する」ことを強くお勧めします。

ロイ

Answer 5

はい、できます。一度にすべてを行うのではなく、モジュールに触れるたびに、モジュールをテストするために必要なものだけを導入してください。

より高レベルの受け入れテストから始めて、そこから段階的に作業を進めていくこともできます (以下を参照してください)。 フィットネス このために）。

Answer 6

まずは基本的な統合テストから始めます。これは他のスタッフからも賛同を得られるでしょう。次に、依存関係のあるコードの部分を分離し始めます。コードのテストがより容易になるため、依存関係の挿入の使用に取り組んでください。バグをテスト可能なコードを書く機会として扱います。