20

既存の大規模な CodeBase の UnitTest を開始する際の問題に対処する方法について、ベスト プラクティスを推奨できる人はいますか? 私が現在直面している問題は次のとおりです。

  • 巨大なコードベース
  • ゼロの既存の単体テスト
  • クラス間の高い結合
  • 複雑な OM (ここでできることはあまりありません - 複雑なビジネス ドメインです)
  • UnitTests/TDD の作成経験の欠如
  • データベースの依存関係
  • 外部ソースの依存関係 (Web サービス、WCF サービス、NetBIOS など)

明らかに、結合を減らしてテストしやすくするために、コードのリファクタリングから始める必要があることは理解しています。ただし、このようなリファクタリングは、UnitTests なしでは危険です (チキンとエッグですか?)。

余談ですが、ドメイン クラスまたは層クラス (ロギング、ユーティリティなど) でリファクタリングと書き込みテストを開始することをお勧めしますか?

4

6 に答える 6

7

UnitTests/TDD の作成経験の欠如

これが最も重要だと思います。

標準的なアドバイスは、最初にすべての新しいコードの単体テストを書き始めて、既存のコードの単体テストを試みる前に単体テストの方法を学習することです。これは理論的には良いアドバイスだと思いますが、ほとんどの新しい作業は既存のシステムの変更であるため、実際に従うのは困難です。

チームと一緒にプロジェクトに取り組み、スキルを適用する過程でスキルを教えてくれる「プレーヤーコーチ」にアクセスできると、あなたは十分に役立つと思います.

そして、私は、Michael Feather のWorking Effectively with Legacy Codeを入手するようにあなたに伝えることが法的に義務付けられていると思います。

于 2009-01-21T00:05:20.370 に答える
1

あなたは自分でこのことを正しく理解することはできません. かなりの説得力が必要です。そこで、適切な議論のための多くの情報とヒントが提供されているこのスレッドを紹介したいと思います。

このような大きなサイズの単体テストを作成できるのは、チーム全体だけです。

于 2009-01-21T07:59:16.467 に答える
0

きもい。私もこれに対処しなければなりませんでした。最善の方法は、既存のコードをテストするために、おそらく使用したくない厄介なツール (NUnitAsp など) に大きく依存することだと思います。その後、リファクタリングを開始できますが、これらのツールによってコードベースがばらばらになることはありません。

次に、リファクタリングするときに、作成中の新しいテスト可能な部分にさらに論理的な単体テストを記述し、元のテストを徐々に廃止します。

于 2009-01-21T00:06:37.937 に答える
0

頑張ってください...ユニットテストを書いた経験がほとんどないので、まず少なくともある程度の経験を積むことをお勧めします。そうしないと、TDD/単体テストを放棄し、単体テストしようとしているシステムに新しいバグを導入する可能性があります。経験を積む最善の方法は、あなたを支援してくれる経験豊富な人を見つけることです。

于 2009-01-21T08:21:21.540 に答える