テストプロジェクトのどこでWCFクライアントエンドポイントを定義しますか？
クラスライブラリがあります。これをServices.dllと呼びます。これは、いくつかのサードパーティの機能のラッパーです。サードパーティから多数のDLLが提供され、それらの "内部" DLLはWCFサービスを呼び出します。
通常、Services.dllが実行されている場合、Webサイトのプロセス内に存在し、サイトに関連付けられているweb.configを使用します。したがって、WCFクライアントエンドポイントを定義する場合は、web.configを編集します。これは非常に簡単です。
しかし今、私は自動化された統合テストスイートを書きたいと思います。もちろん、テストプロジェクトはクラスライブラリ（Services.Tests.dllと呼びましょう）なので、ホスティングプロセスに定義されている構成を使用します。しかし、テストプロジェクトの場合、ホスティングプロセスはVisual Studio自体であると思います。テストプロジェクトは、それ自体の.exeを出力しません。
では、テストプロジェクトのWCFクライアントエンドポイントをどこで定義すればよいでしょうか。どの設定ファイルを編集しますか？ devenv.exe.configを編集しますか？ある種の「サテライト」構成ファイル（例：Services.Tests.dll.config）をセットアップしますか？その場合、Visual Studioテストランナーにその構成を取得させるにはどうすればよいですか？
または... System.Configurationへの呼び出しをインターセプト/モックすることで、設定なしでこれを行う方法はありますか？残念ながら、サードパーティのDLLを変更することはできません。
または、 ServicePointManager の巧妙な使用でオーバーライドして、構成が問題にならないようにしますか？どうすればいいかわかりません。
または...独自のapp.configを使用して、クラスライブラリではなく.exeとして統合テストプロジェクトを作成するのがベストプラクティスですか？
注意してください-私はnot単体テストを実行しています（これらは別々です）。これらは統合テストなので、WCF呼び出しを分離したくありません。それらが必要であり、適切なテストサーバーを指すように構成する必要があります。
使用できる簡単なトリックがあります。
Visual Studioは、テストプロジェクトのapp.configが存在する場合、それをホストプロセスに読み込みます。ただし、テストプロジェクトには通常app.configsがありません。プロジェクトに設定を追加することで、Visual Studioに強制的に作成させることができます。
- プロジェクトを右クリックして、「プロパティ」を選択します。
- 左側のバーにある「設定」オプションに移動します。
- このページに何かを挿入します。何でもうまくいきます。
- プロジェクトを保存します。
これで、テストプロジェクトにapp.configファイルが含まれていることがわかります。 WCFエンドポイント/バインディングをそこに追加するだけで問題ありません。
あなたのようなテストプロジェクトの私のお気に入りのソリューションは、複数の.configファイルテンプレートを維持し、SlowCheetahを使用して、ビルド構成に応じてメインの構成ファイルを変更することです。
https://www.nuget.org/packages/SlowCheetah/
ビルド構成を変更するだけでlocalDev、Dev、QA、Stage、Prod（テストの選択も含む）などの環境をターゲットにして、同じソースコードベースでテストを維持するのは少し簡単でした（継続的なビルド環境では自動的に行われます）。
このように、テストランナーは常に同じ.configファイルを取得しますが、構成ファイルはビルドされた構成に応じて変更されます。