C＃とNUnitを使用してGUIアプリの単体テストを構成する方法

Question

簡単なアプリケーションを顧客に提供するために、小さなサイドプロジェクトを行うように依頼されました。通常、私はすべてのテストニーズを把握しているバックエンドコードで作業しますが、GUIのテストを作成することについての疑わしい喜びはまだないので、設定方法が少しわかりません。 EXEのテストコードとツール。

私の最初の本能は、アプリケーションコードにテストを単に含めることでしたが、テスト固有の多数の依存関係を提供する必要があり、特に顧客に出荷しないように指示されました。また、専用のテストツールでは現金を絞ることもできないため、手元にあるツールを使用する必要があります（StoryQ、RhinoMocks、およびNUnit）、単純なGUIアプリの動作をテストするには、これで十分です。私の知る限りでは、これにより、設計を本当にシンプルに保つことと、テストのために意図的にオーバーエンジニアリングすることとのバランスをとる必要が生じます。別のライブラリでビジネスロジックを使用してアプリを構築し、通常どおりにライブラリに対してテストしている、またはアプリケーション設計で追加されていない追加モジュールを壊すことなく実行可能ファイルにアクセスできるようにする他のメカニズムを見つけているようです本当に必要。

編集：
この質問は、DLL-）ではなく、NUnitと実行可能ファイルの関係をどのように構成するかに関するものであり、プレゼンテーションとビジネスロジックを分離する方法についてではないことに注意してください。
/編集

だから私の質問は：

単体テストを使用して単純なGUIアプリケーションを構成し、状態や動作を適切に確認し、手元にあるツールを使用して、過剰なエンジニアリングに頼ることなく、特定の/推奨される方法はありますか？
DLLとは対照的に、EXEをテストするときにNUnitを起動/構成する方法について基本的なことを見逃しましたか？
このすべてをどのように達成するかの例の方向を教えてくれますか？

これには複数の方法がある可能性があることを理解しているので、あなたの経験に基づいて特定の実装ガイドラインを探しています。

S.Robins · Accepted Answer

私は simoramanの回答への私のコメントの1つで、これを行うにはいくつかの方法を考えたと述べました。私のオプションの1つは、重複したプロジェクトを作成してDLLを生成するという Jalaynの回答の提案に似ていましたが、他のアイデアは、コードが必要なプロジェクトのファイルに単にリンクすることでしたテスト。両方のオプションを機能させることはできますが、理想的とは言えません。

2番目のケースでは、依存関係を最小限に抑えるためにアーキテクチャーを実際に切り離すことができない限り、管理するユニットの依存関係の混乱があります。これは小さなプロジェクトでは問題ありませんが、大きなプロジェクトは簡単に本当の混乱になる可能性があります。ただし、このオプションに対する私の最大の抵抗は、その純粋な優雅さです。確かに私はcouldそれを機能させますが、そうすることで、カプセル化を事実上解除し、パブリックインターフェイスを介してテストするのではなく、ソースを介して直接アセンブリの内部をテストする必要があります。大きなノーノー。同様に、追加のプロジェクトファイルを持つことは、一度に2つのプロジェクトで作業を複製するか、プロジェクトファイルの設定を2つのファイルに自動的に追加する方法を見つけるか、ビルドするたびにプロジェクトフィールドをコピーして名前を変更することを忘れないことを意味します。これはビルドサーバーで自動化できますが、IDEで管理するのは面倒です。繰り返しになりますが、うまくいくかもしれませんが、それはせいぜいクラッジであり、あなたがそれを間違えればさらに悪いことです。

Whatsisnameが私の質問にコメントしたようにして、テストプロジェクトの参照としてEXEを単に含めるのが最善の方法のようです。 EXEはDLLと同じように効果的に扱われ、すべてのnicely layeredクラスにアクセスして何でもテストできることがわかります私のボートを浮かせます。

Jalayn · Answer

私はそう思います：

ビジネステストコードは、ビジネスコードライブラリをテストする別のプロジェクトに含める必要があります。
GUIテストコードは、GUIライブラリをテストする別のプロジェクトに含める必要があります。ここで、実行可能ファイルの代わりにGUIライブラリを構築する方法について、後で答えます。
My.namespace.biz.MyClassがある場合、テストクラスはmy.namespace.biz.MyClassTest（またはMyClassTestCase）である必要があります。
実行可能ターゲットで見つかったコードをテストする場合は、EXEをビルドするセットアップと、テストを起動するライブラリ（DLL）をビルドする別のセットアップが必要です。

JavaまたはC＃（Javaもちろん:-)にEXEの問題がないことを除く）であろうと、これらは私が従うのが好きなルールです。

テスト環境の構成方法については、少なくとも次の2つの選択肢があるようです。

MSBuild を使用する

.projファイルのクローンを作成します（たとえばmyproject-as-dll.proj）。クローンファイルのOutputTypeを「EXE」から「Library」に変更します。 MSBuildコマンドを使用すると、NUnitテストケースを含むプロジェクトへの参照として設定できるライブラリを作成できます。

私にはそれは可能であるように見えますが、私はそれをそれほど正直に使用したことがないので、私にはわかりません。さらに、統合テストサーバーにMSBuildがない可能性があり、Visual Studioから分離できるかどうかはわかりません...

NAnt を使用する

NAntに慣れていない場合は、それを使用してプロジェクトビルドを構成する方法をグーグルで検索する必要があります。たぶんチェックしてみてください this 、少し古いですが、作者はNAntファイルにコメントしており、それが自明であるとわかった場合（編集：彼のファイルを詳細に調べて、私は彼の設定ファイルは非常に再利用可能です）。また、テストケースを実行してコードカバレッジツールを起動するため、ビルドだけではありません。今、私はNAntを使用したことがないことを認めます。そのJavaカウンターパートであり、父親の「Ant」とは対照的に、私は何度も使用しましたが、まったく同じものであり、使用していません。学ぶのはそれほど難しいと思います。

そのツールを使用すると、次のことを可能にする構成を思い付くことができます。

すべてのプロジェクト（ビジネスロジック、GUIなど）を個別のライブラリにビルドする
テストプロジェクトをビルドする
テストを起動します（その特定の部分は NUnit2タスクで実行されます）。
NCover task でコードカバレッジを調べます。

もう少しコードを追加すると、次のこともできます。

統合サーバーで夜間デプロイメントを実行する
統合サーバーでNAntが使用可能な場合は、スケジュールされたタスクの助けを借りて、毎晩の統合テストを起動します

Visual Studioファイル内の何も変更せずにすべてが行われます。そして、実際には、それは私にはオーバーエンジニアリングのようには見えません、それはただのファイルです。すべてが機能するまでには1日、場合によっては2日かかるかもしれませんが、私の意見では適切な設定です。

最後に、プロジェクトの構築、テスト、実行に必要なすべてをクライアントに提供します。私はそれがあなたのプロ意識と品質を念頭に置いてコードを書くという事実を示していると思う傾向があります（エレガントなソリューションを探しているので私にはそう思われます）

Bryan Boettcher · Answer

この質問に対する私の答えを見てみましょう： Winformsソリューション用にMVPを設定するにはどうすればよいですか？

実際に、GUIをどのように階層化し、どのようにテストするかを示すサンプルアプリケーションを作成しました。

編集を読む：開発環境と統合するテストランナーを使用します。私はReSharperを使用しています。

ViSu · Answer

私は数年前にNunit WinFormsを作成していました（おそらく6年間）。特に覚えていることの1つは、単体テストケースですが、エンドツーエンドのテストケースとしても機能することです。場合によっては、フロントエンド（単純なフォーム）でテストすることがあまりないことがあります。したがって、ボタンのクリックでポップアップするメッセージボックスをテストしようとしても、他のレイヤーから他のさまざまなメソッドを誤ってテストしていることになります。自動化できないものもあります。外観、操作性、使いやすさは、自動化された単体テストを使用して自動化することはできません。リリースする前に、いくつかの手動テストを実行する必要があります。

simoraman · Answer

プロジェクトが（最初は）小さいからといって、適切なアーキテクチャが過剰に設計されているわけではありません。テストを記述したいという事実は、プロジェクトが完全に簡単な1回限りのハックではないことを示しています。

使用しているGUIフレームワークについては言及していません。 WPF [〜＃〜] mvvm [〜＃〜] （Model-View-ViewModel）は優れており、すべてのロジックのテストを非常に簡単に作成できます。 WinFormsについて、私は [〜＃〜] mvp [〜＃〜] （Model-View-Presenter）について良いことを聞きました