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

この段階でTDDをどのように導入できますか?

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

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

4

6 に答える 6

27

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

また、Michael Feather の優れた書籍Working effective with legacy codeも参照してください。レガシー コード ベースに TDD を導入しようと考えている人は必読です。

于 2008-09-20T11:21:51.120 に答える
16

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

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

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

個人的には、狂って既存のシステムにテストを改良する必要はないと思います。これは非常に面倒であり、大きなメリットはありません。

要約すると、小規模に開始すると、プロジェクトはますますテストに感染するようになります。

于 2008-09-20T11:22:45.483 に答える
9

はい、できます。あなたの説明から、プロジェクトは良好な状態にあります - 機能テストの自動化は確実に進んでいます! いくつかの側面では、単体テストよりもさらに便利です。TDD != 単体テストであることを思い出してください。すべては、短い反復と確固たる受け入れ基準に関するものです。

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

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

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

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

于 2008-09-20T11:23:42.270 に答える
5

レガシ コードをテストするのに役立つツールの 1 つ (リファクタリングする時間がないと仮定すると、Typemock Isolator: Typemock.com です。これにより、インターフェイスなどを抽出する必要なく、既存のコードに依存関係を注入できます。標準のリフレクション手法 (動的プロキシなど) を使用するのではなく、代わりにプロファイラー API を使用します. これは、sharepoint、HTTPContext、およびその他の問題のある領域に依存するアプリをテストするために使用されています.しかし、これは既存のレガシー コードのリファクタリングを強制せず、時間とお金を節約できる唯一のツールです) また、その他の手法については、「レガシー コードを効果的に使用する」ことを強くお勧めします。

ロイ

于 2008-09-22T01:32:42.283 に答える
3

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

また、より高レベルの受け入れテストから始めて、そこから下に進むこともできます (これについては、 Fitnesseをご覧ください)。

于 2008-09-20T11:19:33.510 に答える
2

私はいくつかの基本的な統合テストから始めます。これは、残りのスタッフから賛同を得ます。次に、依存関係があるコードの部分の分離を開始します。依存性注入の使用に向けて作業してください。コードがはるかにテストしやすくなります。バグをテスト可能なコードを書く機会として扱います。

于 2008-09-20T13:13:39.447 に答える