3

私が取り組んでいる製品は、過去 6 年間開発されてきました。それは、非常に複雑なパーツ WPF/パーツ レガシー アプリケーションへの一般的なデータ入力ポータルとして始まりました。このシステムは、何年もの間、単一の単体テストなしで開発されてきました。ここで、包括的な単体テスト フレームワークの要点が提起されました。私は最近、この製品に取り組むために採用され、「テスト」を行う任務を負っています。過去 6 年間製品に取り組んできたチームが「アジャイル」を採用したため、このプロジェクトにはビジネス ルールのドキュメントや設計ドキュメントがまったくありません。

一部のモジュールの単体テストを作成しようとしています。しかし、メソッドをざっと見ただけではその意図が明らかにならないため、何をモックするのか、テスト フィクスチャをどのようにセットアップするのか、最終的には何をテストするのかがわかりません。また、コードが特定の方法論を念頭に置いて開発されていないことに気付きました。

状況を考えると、Stackoverflow の善良な人々がこの状況を救う方法についてアドバイスをくれるのではないかと考えていました。この一般的な状況について何か述べている本「レガシー コードの操作」について聞いたことがありますが、テクノロジー スタック (C#、VB、C++、.NET 3.5 、WCF、SQL Server 2005)。

4

2 に答える 2

4

私の意見では、統合テストを使用して現在のコードの機能を「安定化」することから始めるのが最善の方法です。後で変更される可能性が低い開始点を持つテストを作成してみてください。統合テストを使用すると、単体テストのために後で行われるリファクタリングによって何も壊れていないという確信を得ることができます。

次のステップは、コードの単体テストです。コードを自由にリファクタリングできる場合は、ロジックをクラスに分離し (例: ビュー レイヤーにロジックを追加)、それらに単体テストを追加できます。このプロセスを使用すると、製品のコードをよりよく知ることができます。

Working with Legacy Code を読むことを強くお勧めします。遭遇する問題の多くにはすでに解決策があります:)

既存のコードやコードをどれだけ変更できるかによっては、レガシー コードの単体テストが難しい場合があります。いくつかのツールを使用できます。たとえば、統合テストを作成する場合は、Whiteフレームワークを使用して GUI を自動化できます。コードに大幅な変更を加えることなく単体テストを作成するために使用できるもう 1 つのツールは、Typemock Isolator (免責事項 - 私は Typemock で働いています) です。このツールを使用すると、運用コードを変更せずにほとんどの依存関係を偽造できます。プロセスを容易にするツールは他にもたくさんあります。それらを見つけて最大限に活用してみてください :)

于 2010-04-02T16:28:10.263 に答える
3

@sc_ray:これはかなり明白に聞こえるかもしれませんが、既存のコードベースに対してテストを書き始める前に、UIを操作するときにMVVMアプローチを使用していることを確認することに集中する必要があると思います。
レガシーアプリであるということは、ifステートメントを使用してUIを直接更新するコードがあることを意味するわけではありませんが、プロジェクトが古いほど、最新のソフトウェア開発スタイルをバイパスしやすくなります。
私が言っているのは、バインディング、コマンド、およびWPFが提供するすべてのすばらしいインフラストラクチャ機能の使用を最適化することを確認することです。そうしないと、ビジネスロジックの重要な部分をテストできず、関連性の低いコードに対してテストを作成する可能性があります...

于 2010-04-02T16:16:18.937 に答える