大丈夫。
そろそろ単体テストに取り掛かるときが来たと思います。誰もがそれについて十分長い間叩いてきているからです。NUnit をインストールし、「単体テストの概要」タイプのチュートリアルをいくつか実行しました。
私は現在、Web アプリの 1 つの再構築を支援する小さなフレームワークをまとめているので、フレームワーク用の VS2008 プロジェクトを作成しました。それを単体テストしたいと思います。
WebControls の単体テストを行うにはどうすればよいですか? メソッドはすべて保護または非公開であり、フレームワークであるため、WebControls 以外にはほとんどありません。
ポインタはありますか？
火傷
本格的なフレームワークを使用せずに、model-view-controllerまたはmodel-view-presenterタイプのアーキテクチャーを実行できます。uiコンポーネントのユニットテストが難しいことはすでにご存知でしょう。それを回避する方法はいくつかありますが、おそらくそのルートに行きたくないでしょう。通常、これによりテストの保守が非常に困難になります。保守の悪夢は、プログラマーがなくても実行できることです:-)
「コントローラー」または「プレゼンター」クラスでテストする機能を分離してみてください。次に、そのクラスをテストします。テストしやすくするために、ユーザーコントロールクラス（ビュー）をインターフェイスの背後に隠し、コントローラーまたはプレゼンターがインターフェイスを介してビューと通信できるようにすることができます。そうすれば、テストでビューをモックアップできます。
これは大変な作業のように聞こえ、回避策のように思えますが、これに慣れれば、UIの動作を変更するのがはるかに簡単になる本当に素晴らしいアーキテクチャです。本当に必要なときに、いつでも「実際の」MVCフレームワークの使用を開始できます:-)
属性assembly:InternalsVisibleToを使用すると、それらのプライベート メンバーにアクセスできるようになります。
Web コントロール プロジェクトのAssemblyInfo.cs ([プロパティ] ノードの下)に配置します。
[assembly:InternalsVisibleTo("YourTestProjectName")]
ASP.NET の最大の問題点を発見しました。単体テストを妨げるシールされたプライベート クラスに関する限り。
これが、ビュー テンプレートとコントローラー ロジックを明確に分離できる MVC フレームワーク (ASP.NET MVC、Castle MonoRail) を TDD 担当者が使用する主な理由です。コントローラーは完全にテスト可能です。
また、ユーザーがWebAiiなどのテストフレームワークを使用してコンポーネントを表示するのと同じように、ブラウザーを介してコンポーネントのテストを確認することもできます。私はそれが機能し、かなりクールであることを見てきました。自動ビルドにプラグインできるとも言われていますが、まだ見ていません。
それが役に立てば幸い ...
これは今では古い記事ですが、私は 2004 年に NUnitASP を使用して asp.net WebControls の nunit テストを作成していました。テストからのコントロールの詳細。テスターは、コントロールと同じアセンブリに配置することもできます (する必要があります)。そのため、それらの間でいくつかのもの (ユーティリティ関数、定数など) を共有できます。
私はこの手法を使用して (他の人はこの手法の変形を使用しています)、今日でも非常に洗練されたコントロールをテストしています。
お役に立てば幸いです。
Ivonna は、Asp.Netコンテキスト内でWebControlを分離してテストできます。session.GetControl（ "Path.ascx"）を呼び出して、必要なすべてのプロパティがあることを確認してください。
上記のMVCフレームワークは、コントロールの機能をテストするための最良の方法です。ただし、それがどのように機能するかをテストすることは少し異なります。
これは完全に問題ありませんが、ユーザーコントロールにいくつかの保護されたメソッドとプロパティを公開させて検証情報を返し、テストユーザーコントロールにそれを継承させることができます。そのコントロールは、フィールドにデータを入力したり、ボタンを押したりすることができます。ちょっと面倒ですが、うまくいく可能性があります。
こちらのRhino Iglooフレームワークもご覧ください。これは、Web フォーム用の侵害された MVC フレームワークです。