そのため、ASP.NET Webページプロジェクトで生産性の高いTDDを実践し、テストを実行するたびにサーバーを起動しようとしていますが、それほど高速ではありません。そのため、[HostType（ "ASP.NET"）]属性を使用せずにテストを実行する方法を見つけようとしていますが、常にエラーが発生します。リソースファイルにApp_GlobalResourcesフォルダーを使用していますが、これは問題の1つです。属性を削除するときに、[TestMethod]を保持するだけで（MStestを使用）、リソースを見つけることができません。したがって、リソースアセンブリが見つからないと仮定していることに注意してください。
それで、誰かが以前にこれをしたことがありますか？何か経験はありますか？
そして、「MVCに変換してみませんか」というコメントは、アプリを大きくするだけで、時間はほとんどかかりません。多分それは数年以内に起こるでしょう、多分それ以上、多分決して起こらないでしょう。
ASP.NET Webアプリをテストした私の経験は苦痛でした（あなたもそうです！）MVCコメントに抵抗する
私の最善のアドバイスは、エリアに触れるたびに少しずつステップを踏んで、テストしやすくすることです。たとえば、コードの任意のビットについて、参照できる独自のアセンブリに引き出すことができます。
最初の候補はあなたのリソースファイルです。次に、テストでは、ジャンプする「App_」フープなしでその衛星アセンブリを参照できます。
私が取ったアプローチには、各ページのプレゼンター クラスの作成が含まれていました。プレゼンターが UI を制御するために必要なメソッドとプロパティを使用して、ページが実装するインターフェイスを作成します。インターフェイスへの参照とともに、すべてのロジックがプレゼンターに入ります。ページはプレゼンターを参照し、自分自身を渡します。
得られる利点は、UI を機能させるためのコードのみをページに含める必要があることです。発表者はほとんどの作業を行います。UI にアクセスできるため、インターフェイスを介して UI を制御できます。アクセスはインターフェイス経由であるため、模擬 UI を使用してプレゼンターをテストできます。
ページが大幅に簡素化され、アプリのロジックをサポートするコードと UI を機能させるコードが大幅に区別されていることがわかりました。また、Web フォームでは必ずしも簡単ではないサービス クラスと IoC の導入も簡単になりました。