したがって、単体テストが必須であることはわかっています。新しいモジュールを追加するときは、TDD が適していると思います。たとえ、実際には、私は実際にそれをしません。実際、コードのコメントに少し似ています。
本当のことは、UI と、イベントを生成するより一般的なオブジェクト (ユーザー コントロール、非同期データベース操作など) を単体テストする方法について頭を悩ませていることです。
私のコードの多くは UI イベントに関連しているため、単体テストを開始する方法さえよくわかりません。
そこにいくつかの入門書とスターター ドキュメントがあるはずですか? いくつかのヒントとヒント？
私は一般的にC＃（2.0および3.5）で作業していますが、これが質問に厳密に関連しているかどうかはわかりません。
ユニット テストとは、記述したコードのユニットをテストすることです。単体テストでは、ボタンをクリックするとイベントが発生することをテストするのではなく、そのクリック イベントによって実行されるコードが想定どおりに動作することをテストする必要があります。
本当にやりたいことは、UI レイヤーがそのコードを自信を持って実行できるように、基礎となるコードが本来の動作をテストすることです。
UI テストに苦労している場合は、 これをお読みください
自動化のコストに対するメリットが最小限である場合は、UI を手動でテストします。UI スキンの下のすべてを容赦なくテストします。Humble Dialog、MVC、またはバリアントを使用して、ロジックと UI を区別し、疎結合に保ちます。
ロジックとプレゼンテーションを分離する必要があります。MVP (Model-View-Presenter)/MVC (Model-View-Controller) パターンを使用すると、UI イベントに依存せずにロジックを単体テストできます。また、White フレームワークを使用してユーザー入力をシミュレートすることもできます。Microsoft のPatterns&Practices デベロッパー センターにアクセスすることを強くお勧めします。特に、複合アプリケーション ブロックと Prism をご覧ください。テスト駆動設計に関する多くの情報を入手できます。
アプリケーションの外部と通信する部分 (つまり、UI、データベースなど) は、単体テストの際に常に問題になります。これを回避する方法は、実際にはこれらのレイヤーをテストするのではなく、できるだけ薄くすることです。UI については、テストする価値のない単純なダイアログまたはビューを使用して、すべてのロジックをコントローラーまたはプレゼンター クラスに配置できます。次に、モック フレームワークを使用するか、独自のモック オブジェクトを作成してビューの偽バージョンを作成し、プレゼンターまたはコントローラーでロジックをテストできます。データベース側でも同様のことができます。
イベントのテストは不可能ではありません。たとえば、イベントがスローされた場合に例外をスローしたり、イベントがスローされた回数をカウントしたりする匿名メソッドをイベントにサブスクライブできます。