私は既存のasp.net webformsアプリケーションを使用していますが、ユニットテストを追加したいのですが、正確にどのように行うべきかはわかりません。ユニットテストを既存のasp.net Webフォームアプリケーションに追加する
アプリケーションはデータベース駆動型で、高度なフォーラムと比べることができます。ロジック、データアクセス、およびプレゼンテーションは、大部分が分離されています。
どのような方法でテストする必要がありますか？
データベースとテストデータの処理方法を教えてください。
これを支援するツールはありますか？
最初に決定する必要があるのは次のとおりです。ユニットテストを追加する動機は何ですか？
単体テスト（私は厳密にTDDを自分で練習しています）には、多くの優れた理由がありますが、どちらが主な原動力であるかを知ることで、どのテストを最初に書くか決定するのに役立ちます。
ほとんどの場合、過去に最も痛みを感じているアプリケーションの領域について単体テストを書くことに集中する必要があります。
多くの経験から、ソフトウェアが最初に単体テストなしで書かれた場合、後で単体テストを改造することは困難であることが示されています。 Working Effectively with Legacy Codeは、テストされていないソフトウェアプロジェクトをテスト可能にする方法に関する貴重な指針を提供します。
あなたのウェブフォームが（フォームの検証をバイパスして）呼び出すバッキング方法をテストする可能性が高いです。ロジックとデータのアクセスをテストできるようになります。
テストデータに関しては、別個のテストデータベースが最適なオプションです。さもなければ私はテストメソッドが完了したらテストデータを削除することをお勧めします。
データベース関連のユニットテストでは、ユニットテストを実行するために、独立した安定したテストデータベースを使用します。
また、コミットされていないTransactionScopeにデータ変更テストをラップするため、後続のテスト実行のためにデータ変更がロールバックされます。私たちはこれが本当にうまくいくことを見出しました。
ツールの面でも、私はASP.NET Webフォームアプリケーションをテストする方法を探しています。モデル部分（データアクセスなど）では、NUnit、ローカルSQL Express dbを使用し、すべてのテストを実行する前にスキーマを作成するコード（私たちがチェックインした.sqlファイルから）を作成しました。
テストの間に、NUnit DataRollback拡張機能を使用して、実行ごとにdb変更をロールバックします。
Railsの機能テストのように、ページのロジックをテストする良い方法はまだ分かりません。カバレッジの観点からは、壊滅的です。あなたは多くのロジックをモデルに戻すことができますが、重要なファイルの背後にあるコードには常にコードがあり、中断する可能性があり、単体テストを取得したいと考えています。