wcf - プロセスが不足しているユニットテストアセンブリ

Question

「プロセス外アセンブリ」のテスト経験がある人はいますか？プロセス外でアクティブ化するように構成されたいくつかのCom+（サービスコンポーネント）およびWCFサービスをテストしていますが、これらの状況でテストするためのベストプラクティスがわかりません。

私が行ったことは、パブリッククラスに、アクティブ化時に構築できる独自のIOCコンテナを与えたことです。これは正常に機能しますが、2つの理由でユニットテストを試みるとすぐに問題が発生します...

1. 単体テストは別のプロセスで実行されているため、挿入する依存関係オブジェクトはシリアル化可能である必要があります。追加のモジュール（ninject）をcom + kernel / iocコンテナーにロードしたい場合は、シリアル化できるように独自のモジュールを作成する必要があります。テストを行うためだけにシリアル化できるようにするのは気が進まない。

2. アウトプロセスアセンブリはGACにインストールする必要があり、Com+の場合は登録する必要があります。テストする前にインストールする必要があるため、テストは面倒です。

現時点では、これにアプローチする方法は2つしか考えられません。

1. アセンブリを処理中に実行するように構成を変更したテストを実行するための別の作業コピーを用意します。明らかに、これは理想的ではありません。テスト可能にするためだけにコードを変更しているからです。機能的な変更がないので、これで生きることができましたが。

2. 単体テストをCom+またはWCFコンポーネントから継承して、テストを同じプロセス境界で実行できるようにします。（これには、ユニットテストをGACにインストールする必要があります）

Answer 1

一般的に、私は一方のプロセスのコンポーネントともう一方のプロセスのコンポーネントのテストを作成しますが、必ずしも真ん中のポイントを気にする必要はありません（できるだけ薄くしてください）。

2つの別々のプロセス間の相互作用をテストしている場合、それはほぼ定義上、統合テストだと思います。

Answer 2

私はあなたの最初の提案に行きます：アセンブリがプロセスで実行されるテストを実行するための別の作業コピーを持っています。

利点は次のとおりです。

• これをシステムで機能させると、構成なしで他のチームメンバーのマシンで実行されます。

• プロセス間呼び出しを行わないため、テストは大幅に高速に実行されます。

私が最初にテスト駆動開発を始めたときのことを覚えています。あなたと同じように、自動テストに対応するためだけにコードを変更するのは気が進まなかった。徐々に考え方を変えていきました。ライブラリは、本番クライアントコードとテストという2つの等しく重要なクライアントにサービスを提供する必要があります。