Biztalk の要求/応答ポートによって消費される WebService をモックする

https://stackoverflow.com/questions/256897

05-07-2019
|

質問

使っていますビズユニット Biztalk オーケストレーションの単体テストを行いますが、一部のオーケストレーションは WebService を使用するため、これらのテストは単体テストというより統合テストに似ています。

Windows フォームアプリケーションから Web サービスをテストするために、生成されたプロキシオブジェクトをモックするモッキングフレームワークの使用には慣れていますが、要求/応答ポートでより統合された方法で実行できるようにしたいと考えています。 ?

この問題にどのように取り組みますか?

解決

これは、BizTalk開発者としての私の主な苛立ちの1つです。BizTalkは単体テストに適していません。 BizTalkアプリケーションへのインターフェイスの99％がメッセージベースであり、膨大な数の入力が可能であるという事実から、オーケストレーションの不透明な性質まで、BizTalkは機能単位をテストする実際の方法を提供しません...単位。

BizTalkでは、統合テストが町で唯一のゲームであることが残念です。

その結果、ケビン・スミスの側に過失がないため、BizUnit（IMO）は誤った呼び名です。より良い名前は、おそらくBizIntegrationItです。 BizUnitは、統合テストを支援するさまざまなツールを提供します。ファイルが特定のディレクトリに書き込まれたかどうかを確認したり、HTTPRequestをBizTalk HTTPReceiveの場所に送信するなど、テストの大部分はすべて厳密に言えば統合テストです。

今、私はその暴言を聞きました、あなたが求めているのは私が長い間考えてきたことです、私が小さな変更をするという本当の自信を与える自動化された単体テストを作成する能力マップがダウンストリームの他の何かを突然壊すことはなく、外部サービスへの依存を取り除く方法もありません。

これを行うための良い方法を考えたことはありませんが、以下は動作するはずの解決策です。この特定の形式で一緒に。

外部呼び出し（まだ存在しない場合もある）への呼び出しをモックしたいという要望がある場合、外部呼び出しを実際に行う必要はなく、そのサービスに対する期待を設定する能力を持ちたい呼び出して、応答の性質を指定するために考えられる唯一の方法は、カスタムアダプターを開発することです。

カスタムアダプターを使用したWebサービスのモック

カスタムの要求/応答アダプターを作成する場合、SOAPアダプターの代わりに送信ポートにプラグインできます。次に、Webサービスのモックとして動作できるようにするアダプターのプロパティを指定できます。このアダプターの概念はループバックアダプターに似ていますが、内部のモックロジックを許可します。

アダプターのプロパティとして含めたいもの：

期待されるドキュメント（おそらく、BizTalkアプリケーションがWebサービスに送信することを期待する例を指定するディスクの場所）。
応答ドキュメント-アダプタがメッセージングエンジンに送り返すドキュメント。
ドキュメント要素のルックアップ値など、テストに対する特定の期待。

カスタムアダプタにディスクへの書き込みを行わせ、BizUnitステップをセットアップして、書き込まれたファイルを検証することもできます。

カスタムアダプターの構築は簡単ですが、可能ですが、 BizTalkアダプターウィザードから良いスタートを切ることができます。およびカスタムアダプターの展開に関する記事こちら。

ウィザードによって生成されたコードにバグがあるため、 new Guid（＆quot;＆quot;）、を new Guid（）に変更する必要があります。

BizTalk SDKでカスタムアダプタを構築する例もいくつかあります。

別のオプションは、こちら、すべてのロジックはhttpページにあります。これはおそらく、http呼び出しを行い、テストをリッスンするIISポートをセットアップすることに満足している場合は、おそらくより簡単です。

ユニットテストの開始

.batファイルを使用して、バインディングファイルをBizTalkアプリケーションにインポートできます。

実行する各テスト、および標準のアプリケーションセットに対して新しいバインディングファイルを作成する場合

他のヒント

BizUnitExtensions（www.codeplex.com/bizunitextensions）の共著者として、「unit」という名前に同意します。 BizUnitでは混乱を招く可能性がありますが、Biztalkの場合、「統合テスト」は単体テストです。一部のBiztalkユーザーは、モックを使用してパイプラインコンポーネントと他のテストハーネス（+ BizUnit / Extensions）をテストし、スキーマとマップをテストすることに成功しています。

オーケストレーションは残念ながら不透明です。しかし、それには十分な理由があります。

（a）メッセージボックスの巨大なサブスクリプションシステムのため、オーケストレーションはアクティブ化されるときなどに使用するため、一部の「仮想」を起動することはできません。オーケストレーションをホストするプロセス（パイプラインで実行可能。TomasRestrepoはこれらのラインに沿って何かを実行しました）。

（b）また、この仮想プロセスは永続化と脱水をどのように処理しますか？ WFを使用している人は、ワークフローを完全にテストしようとすると同じ問題を抱えることになると思います。

（c）C＃を直接操作しないため、「注入」する方法はありません。モックオーケストレーションコードへのインターフェース。

（d）オーケストレーションは、実際には「ユニット」ではありません。その複合要素。ユニットは、メッセージボックスと式図形を介して呼び出される外部コンポーネントとの間で送受信されるメッセージであるため、モックWebサービスインターフェイスを挿入できたとしても、モックメッセージボックスや相関セットなどを挿入することはできません。

オーケストレーションのためにできることの1つ（およびこれを行うためにBizUnitExtensionsライブラリへの追加を検討している）は、OrchestrationProfilerツールとリンクすることです。このツールは、すべての形状と個々のステップが実行されたことを確認します（おそらく実行にかかった時間）。これは、オーケストレーションをもう少し白いボックスにするのにかなり遠くなる可能性があります。また、オーケストレーションデバッガーが多くの変数値を表示することを考慮すると、変数の値を表示するAPIを介してその情報を取得できることは確かです特定のインスタンスの特定のポイントにありました。

リチャードの質問に戻りますが、私の前の開発チームには解決策がありました。基本的に、私たちがしたことは、着信サービス要求を解析し、事前設定された応答を返す汎用の設定可能なHttpHandlerを書くことでした。返される応答は、XPathなどの条件に基づいて構成可能でした。 BUILDおよびDEVバインディングファイルでは、Webサービスのエンドポイントはモックでした。これは、BUILDおよびDEV環境を実際のサードパーティWebサービスから分離するのに見事に機能しました。これは、「最初に契約を結ぶ」ことにも役立ちました。 Webサービスの作成者が実際のサービスを構築している間に、モックを構築し、オーク開発者がそれを使用するアプローチ。

[Update：17-FEB-09：このツールは現在codeplex上にあります： http：//www.codeplex .com / mockingbird 。このアプローチがおもしろいと思われる場合は、それをチェックして、あなたがツールについてどう思うか教えてください]

今、誰かが古い「WHAT ABOUT MOCK OBJECT FRAMEWORKS」を投げる前に、上記のユーティリティはBiztalkの「消費者」と非Biztalkの消費者の両方に使用されましたが、私はNMock2とも連携しており、CLR消費者を記述するときにインターフェイスをモックし、期待を設定する優れた方法であることがわかりました。（MoQやTypeMockなどを近々調査する予定です）。ただし、上記の理由により、オーケストレーションでは機能しません。

これがお役に立てば幸いです。

よろしく、

ベンジー

しないでください。

任意のインターフェイスに対してテストを行わず、それらのモックを作成しないでください。

ほとんどの人は、開発者（ユニット）のテストを、単一クラスなどの機能の重要な個々のユニットをテストすることを目的としています。一方、主要なサブシステムまたはシステム全体の顧客（受け入れ/統合）テストを実行することも重要です。

Webサービスの場合、重要な機能のユニットは、通信配線の背後で、意味のあるサービスを実際に実行するクラスに隠されています。これらのクラスには、機能を検証する個別の開発者テストクラスが必要ですが、Webサービス指向の通信配線は一切必要ありません。当然ですが、明らかにではないかもしれませんが、これは、機能の実装を配線の実装とは別にする必要があることを意味します。そのため、開発者（ユニット）のテストでは、その特別な通信配線は一切見られません。これは統合の一部であり、（適切に）「プレゼンテーション」として見ることができます。「ビジネスロジック」ではなく問題。

顧客（受け入れ/統合）テストは、はるかに大規模な機能に対処する必要がありますが、「プレゼンテーション」に焦点を当てることはできません。問題。これは、Facadeパターンの使用が一般的である場所です。つまり、統一された粗い、テスト可能なインターフェイスを持つサブシステムを公開します。繰り返しますが、Webサービス通信の統合は無関係であり、個別に実装されます。

ただし、実際にWebサービス統合を含む個別のテストセットを実装することは非常に便利です。ただし、その統合の片側のみをテストすることは強くお勧めします。エンドツーエンドでテストします。これは、実際の製品コードと同様に、Webサービスクライアントであるテストを構築することを意味します。実際のアプリケーションとまったく同じ方法でWebサービスを使用する必要があります。つまり、これらのテストは、そのようなアプリケーションを実装する必要がある人（ライブラリを販売している場合の顧客など）の例となります。

では、なぜそんなトラブルに行くのですか？

開発者テストでは、アクセス方法に関係なく、機能が小規模で機能することを確認します（プレゼンテーション層はすべてビジネスロジック層内にあるため、プレゼンテーション層とは無関係です）。
お客様のテストでは、ビジネスロジック層のインターフェイス境界で、アクセス方法に関係なく、機能が大規模に機能することを確認します。
統合テストでは、プレゼンテーション層がビジネスロジック層で動作することを確認します。これは、基になる機能を無視できるようになったため、管理可能になりました（上記で個別にテストしたため）。つまり、これらのテストは、かわいらしい顔（GUI？）とコミュニケーションインターフェイス（Webサービス？）の薄いレイヤーに焦点を当てています。
機能にアクセスする別の方法を追加する場合、その新しいアクセス形式（プレゼンテーション層）の統合テストを追加するだけです。開発者と顧客のテストにより、コア機能が変更されていないことを確認します。
Webサービス専用のテストツールなど、特別なツールは必要ありません。製品コードで使用するのと同じように、製品コードで使用するツール/コンポーネント/ライブラリ/テクニックを使用します。これにより、他の人のツールをテストしていないため、テストがより有意義になります。特別なツールを購入、展開、開発、保守する必要がないため、多くの時間とお金を節約できます。ただし、GUIを使用してテストする場合（そうしないでください！）、その部分に特別なツールが1つ必要になる場合があります（例：HttpUnit？）。

では、具体的に見てみましょう。カフェテリアの毎日のメニューを追跡するための機能を提供したいとします（建物内に独自のカフェがある巨大企業で働いているため、like mine）。 C＃をターゲットにしているとしましょう。

メニュー、メニュー項目、その他のきめ細かい機能とその関連データ用のC＃クラスを作成します。 nUnitを使用して開発者テストを実行するnAntを使用して自動ビルドを確立します（そうしますか？）。毎日のメニューを作成し、これらすべての小さなピースで確認できることを確認します。

今後の方向性についてある程度の考えがあるので、ほとんどのきめの細かい部分を非表示にしつつ、いくつかのメソッドを公開する単一のクラスを作成することにより、Facadeパターンを適用します。クライアントと同じように、新しいファサードを介してのみ動作する個別の顧客テストセットを追加します。

今、巨大企業のナレッジワーカーが今日のカフェテリアメニューをチェックするためのWebページを提供することにしました。 ASP.NETページを作成し、ファサードクラス（MVCを実行している場合にモデルになる）を呼び出して展開します。顧客テストによってファサードクラスを既に徹底的にテストしており、単一のWebページが非常に単純であるため、Webページに対して自動化されたテストを書くのを控えます。少数の仲間のナレッジワーカーを使用した手動テストがトリックを行います。

その後、その日のランチを事前注文できるなど、いくつかの主要な新機能の追加を開始します。既存のテストが既存の機能の破壊を防ぐことを知って、きめ細かいクラスと対応する開発者テストを拡張します。同様に、インターフェイスの成長に伴い、おそらく新しいクラス（MenuFacadeやOrderFacadeなど）をさらに分割し、顧客テストに同様の追加を加えて、ファサードクラスを拡張します。

今、おそらく、Webサイトの変更（2ページはWebサイトですよね？）により、手動テストが不十分になっています。そのため、HttpUnitに匹敵するシンプルなツールを導入して、nUnitでWebページをテストできるようにします。一連の統合/プレゼンテーションテストを実装しますが、ファサードクラスのモックバージョンに対するものです。ここでのポイントは、単にWebページが機能するということです。ファサードクラスが機能することは既にわかっています。テストでは、データがモックファサードを介してプッシュおよびプルされますが、データが正常に反対側に到達したことをテストするためだけです。これ以上ない。

もちろん、当社の大成功により、CEOはWebアプリケーションをmega-corpのBlackBerryに公開するよう要求（要求）するよう促されます。そこで、いくつかの新しいページと新しい一連の統合テストを実装します。新しいコア機能が追加されていないため、開発者や顧客のテストに触れる必要はありません。

最後に、CTOは、カフェテリアアプリケーションをメガコーポレーションのすべてのロボットワーカーに拡張することを要求（要求）しました。ここ数日、彼らに気付きましたか？そこで、ファサードを介して通信するWebサービスレイヤーを追加します。繰り返しますが、コア機能、開発者テスト、または顧客テストに変更はありません。同等のWebサービスAPIでファサードを公開するクラスを作成することにより、アダプター/ラッパーパターンを適用し、そのAPIを使用するクライアント側クラスを作成します。新しい一連の統合テストを追加しますが、それらはプレーンなnUnitを使用してクライアントサイドAPIクラスを作成します。これは、Webサービスのワイヤリングを介してサービスサイドAPIクラスと通信し、モックファサードクラスを呼び出し、ワイヤリングが機能することを確認します。

このプロセス全体を通して、生産プラットフォームとコード、選択した開発プラットフォーム、自動ビルドとテスト用のいくつかのオープンソースコンポーネント、明確に定義された一連のテスト以外に重要なものは必要ありませんでした。また、本番環境で使用していないものはテストしておらず、2回もテストしていないことに注意してください。

最終的に、成熟した（仮想的に）実証済みの機能の強固なコア（ビジネスロジック層）になりました。プレゼンテーション層には、デスクトップをターゲットにしたWebサイト、BlackBerryをターゲットにしたWebサイト、Webサービスの3つの独立したプレゼンテーション層があります。

免責事項:私はタイプモックで働いています。

何をする必要があるのか正確にはわかりませんが、次のリンクから始めるのが良いと思います。

これは非常に興味深い質問であり、まだ一般的な答えはありません。 SoapUIの使用を提案する人もいますが、実際にテストする時間はまだありません。このページは興味深いかもしれません。

別の方法は、WebDev.WebHost.dllを何らかの方法でラップして使用することかもしれません... Phil Hakkckがこの投稿。

SO こちらでも以前に説明されています。

これに対する別の解決策を見つけた場合はお知らせください！

これはそれを行う方法です：

しかし、リチャードの質問に戻って、私の前の開発チームには解決策がありました。基本的に私たちがしたことは汎用の構成可能なHttpHandler 着信サービス要求を解析し、返されたプリセット応答。の返される応答は構成可能でした XPathなどの条件に基づいて

しばらくの間これを行う必要はありませんでしたが、Biztalkアプリをテストするときは常にsoap uiまたはweb service studioを使用しました。努力せずに異なる入力値をテストすることができました。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow