0

私は、UIレベルで効果的に単体テストと統合テストを行うためのソリューションを考え出すという任務を負っています。残念ながら、Windowsフォームには多くのコードビハインドがあります。また、ブラウンフィールドプロジェクトがあり、ゆっくりとWPFに移行しています（新しい機能はWPFにあり、大きな変更が必要な場合は古い機能をWPFに移行しています）。

WPFのすべては、（データベースを除いて）ずっとユニットテストされています。私はMVVMアプローチを使用しているので、ほとんどすべてのコードがそこにあります。

ただし、展開前のテストには多くの時間がかかり、そのほとんどを自動化する方法が必要です。

そうは言っても、私が言及しているこのテストはUIで行う必要があります。

ロジックの一部はコードビハインドで実行され、一部はデータベースで実行されるため、Windowsフォームの一部は統合テストを行う必要があります。

WPFウィンドウは、UIレベルでユニットテスト可能である必要がありますが、統合テストも必要です。

私はそれが1つの質問に飲み込むことがたくさんあることを知っていますが、誰かが何か推奨事項がありますか？

4

2 に答える 2

2

(この回答は、コードの統合テスト方法に関するものです: WinForms と WPF。)

テストの保守を容易にするために多くの時間とエネルギーを投入するようアドバイスするだけです。

Visual Studio 内からテストを変更して実行できることを確認してください。

テストのために別のツールを起動しなければならないという追加の負担は、おそらく開発者がそれを行わなくても十分でしょう (私はそれが起こるのを見てきました)。したがって、これを可能にするUI テスト ツールを見つけてみてください。

テストを記録しないでください。

快適ではありますが、記録されたテストの結果のコードは読みにくく、理解しにくく、多くの重要でない詳細が含まれている可能性があります。テストを変更する必要がある場合は、おそらくそれらを再記録する必要があります。テストは、システムをどのように動作させたいかを仕様化するというよりも、システムがどのように動作するかを示すドキュメントのようなものになります。

テスト用の共有インフラストラクチャを作成します。

ウィンドウの動作を表すオブジェクト内のウィンドウ/フォームの抽象化を作成します。このようにして、これらのオブジェクトの実装の詳細を非表示にし、実際のテストをコンパクトにして読みやすくすることができます。このインフラストラクチャがあれば、新しいテストを簡単に追加できます。また、実装の詳細が変更された場合、テストに変更を加える場所は 1 つだけです。それはインフラストラクチャです。

Web テストの世界では、これはpage object patternと呼ばれます。

C# でのテストの例:

ApplicationFake application = new ApplicationFake();

// ApplicationFake.Start() starts the application resulting in that main form opens.
// Start() returns an object that represents the actions that the user can perform on
// the main form.
// The Start() method might contain an assert that the main form was actually opened.
MainFormFake mainForm = application.Start();

// Performing an action that opens a new form returns a representation of the new form,
// in this case the object SomeFormFake.
SomeFormFake someForm = mainForm.ClickOpenSomeFormButton();

// The form fakes exposes properties that returns the forms' observable state.
Assert.That(someForm.Title, Is.EqualTo("Some Form's Title"));
于 2012-07-13T08:24:12.373 に答える
1

Torbjornの答えには完全に同意しますが、いくつかの点を追加したいと思います。

小さく始める

ページオブジェクトパターンはテストを簡素化するための優れた方法ですが、抽象化を正しく行うには長い時間がかかることがわかります。必要なものを抽象化することから始めて、時間をかけてゆっくりと追加していきます。

付加価値を付けます

やりすぎて、エンドツーエンドの回帰テストを作成しようとしないでください。代わりに、価値を付加するテストの作成に焦点を合わせます。たとえば、アプリケーションがエラーなしで起動することを示す単一のテストは非常に有用であり、ビルドプロセスに関する早期のフィードバックを提供できます。そこから出てください。

「深い」と「浅い」のバランスをとる

ユーザーインターフェイスをテストするためのいくつかの異なる哲学があります。それらの間のミックスを確立します。

明らかなアプローチは、本番環境のような設定でアプリケーションをテストして、アプリケーションが「フロントツーエンド」で動作することを実証することです。これらは、コードのすべての部分を実行する「深い」統合テストであり、便利です。また、通常は外部サービスなどに依存しているため、非常に遅くなる可能性があります。多くの場合、信頼性を確保するには、有効な環境を確保するために、テスト実行の間にアプリケーションを再起動する必要があります。

このアプローチのわずかな変更は、スタブアウトされたサービス（偽の製品カタログ、偽の認証プロバイダーなど）を使用してアプリケーションをテストすることです。これらは、ユーザーインターフェイスが統合されたときに機能することを示す「浅い」テストです。考慮すべきネットワーク遅延などの同じ物理的制約がないため、通常は少し高速に実行されます。プレゼンテーションの詳細やその他のエッジケースにさらに焦点を当てることができます。

さらなる変更は、ユーザーインターフェイスの一部を分離し、それらをテストハーネスで実行することです。これらのテストは、アプリケーション全体を起動するのと同じオーバーヘッドがないため、以前のアプローチよりもはるかに高速に実行されます。これらのテストを使用して、色と高度に専門化されたプレゼンテーションの懸念を主張します。

安定したら繰り返す

手動の回帰テストの代わりに機能テストを作成する場合は、開発によってその機能が安定するまで待ってから、自動化を作成することをお勧めします。開発中に自動化を書き始めると、常にテストを書き直します。開発中に自動化したい場合は、覚えておいてください。小さなことから始めてください。

早期のフィードバックを得る

UIの自動テスト（機能テストとも呼ばれます）は便利ですが、非常に時間がかかる場合があります。（実行が完了するまでに数時間かかるのを見てきました。）テストスイート全体を1日1回実行すると、フィードバックループが長すぎて、誤検知やメンテナンスの問題などが発生することがわかります。

可能であれば、機能テストをビルドプロセスに統合してみてください。テストスイートに時間がかかりすぎる場合は、ビルドパイプラインがビルドの一部として重要なテストを検証できるように、いくつかのテストを統合する方法を見つけてください。

于 2012-07-13T15:35:09.833 に答える