ユニットWCFビヘイビアエクステンションのテスト

Question

これは私を狂ってしまいます。私は、エラーがある場合、リクエストのContent Responseを変更するために使用する拡張子を持っています。基本的には、すべてがうまくいけばJSONに通常通りシリアル化されますが、未処理の例外が発生した場合は、別のオブジェクトに基づいてシリアル化します。

私たちはこれを回避するために単体テストが必要ですが、私はそれらの書き方を理解できません。それが有効であることを検証する手段は、StatusCode、障害メッセージインスタンス、および応答のContentTypeを中心に回転します。

応答を戻すように変更するには、WebOperationContext静的クラスを使用します。私はこれを嘲笑する例を見てきましたが、実際のコードに浸透し始める特別なロジックをハードコードする必要があるようです。

WCFビヘイビアエクステンションをユニットテストするための最良の方法は何ですか？

Answer 1

ほとんどのクラスが封印されているか、内部コンストラクタを持っているため、私は同様の状況があり、少なくともMoqを使ってWCFをモックすることはできませんでした。私が何をしたか

は私の行動はただIParameterInspectorとIClientMessageInspectorを適用します（私の場合、私は両方が必要）と検査官のタイプに応じて、必要なAfterCallまたはBeforeCall、またはいずれか1のどちらかにすべての私のロジックを入れて持っていました。

こうして、私が気にかけたすべてのロジックをテストすることができました。 実際のWCFの振る舞いはテストされませんでしたが、実際には2人のインスペクタを追加するだけでした。