BizUnitを使用して Biztalk オーケストレーションの単体テストを行っていますが、一部のオーケストレーションは WebService を使用しており、これらのテストは単体テストというよりも統合テストのように見えます。
Windows フォーム アプリケーションから Web サービスをテストするために、生成されたプロキシ オブジェクトをモックするモック フレームワークを使用することに慣れていますが、要求応答ポートでより統合された方法でそれを実行できるようにしたいと考えています。 ?
この問題にどのように取り組みますか?
これは、BizTalk 開発者としての私の最大の苛立ちの 1 つであり、BizTalk は単体テストに適していません。BizTalk アプリケーションへのインターフェイスの 99% がメッセージ ベースであり、膨大な数の可能な入力があるという事実から、オーケストレーションの不透明な性質まで、BizTalk は機能ユニットをテストする実際の方法を提供しません...ユニット。
BizTalk の場合、悲しいことに統合テストが唯一のゲームになることがよくあります。
その結果、Kevin Smith 側に過失がないため、BizUnit (IMO) は誤称になります。より適切な名前は、おそらく BizIntegrationIt でしょう。BizUnit は、統合テストを支援するさまざまなツールを提供します。ファイルが特定のディレクトリに書き込まれたかどうかの確認や、BizTalk HTTPReceive の場所への HTTPRequest の送信など、そのテストの大部分はすべて、厳密に言えば、統合のテストです。
私がその暴言を吐き出したので、あなたが求めているのは、私が長い間考えていたことです。マップに小さな変更を加えたことが勝ったという本当の自信を与える自動化された単体テストを作成する機能です。外部サービスへの依存を取り除く方法と同様に、ダウンストリームの他の何かを突然壊さないでください。
私はこれを行う良い方法を考えたことはありませんが、以下はうまくいくはずの解決策です.
そのため、実際に外部呼び出しを行う必要がなく、そのサービス呼び出しに期待を設定し、応答の性質を指定する機能が必要な外部サービス (まだ存在しない可能性がある) への呼び出しをモックしたい場合、私が思いつく唯一の方法は、カスタム アダプターを開発することです。
カスタムの要求/応答アダプターを作成する場合は、SOAP アダプターの代わりにそれを送信ポートにプラグインできます。その後、アダプタが Web サービスのモックとして動作できるようにするプロパティを指定できます。このアダプターは、ループバック アダプターと概念が似ていますが、内部のモック ロジックを使用できます。
アダプタのプロパティとして含めることができるもの:
また、カスタム アダプターをディスクに書き込み、BizUnit ステップをセットアップして、書き出されたファイルを検証することもできます。
カスタム アダプターの構築は簡単ではありませんが、可能です。BizTalk アダプター ウィザードから始めるとよいでしょう。カスタム アダプターの展開に関する記事はこちら にあります。
new Guid(""),ウィザードによって生成されたコードにバグがあるため、 に変更する必要がありますnew Guid()。
BizTalk SDK でカスタム アダプターを作成する例もいくつかあります。
もう 1 つのオプションは、こちらで説明されているように、プレーンな http ページと HTTP 要請応答を使用することです。すべてのロジックは http ページに入ります。http 呼び出しに満足し、IIS ポートをセットアップしてテストをリッスンする場合、これはおそらくより簡単です。
.bat ファイルを使用して、バインド ファイルを BizTalk アプリケーションにインポートできます。
実行するテストごとに新しいバインド ファイルを作成し、標準的なアプリケーションのセットアップを行う場合は、適切なバッチ ファイルを実行して適切なバインドを適用できます。
各バインド ファイルは、モック カスタム アダプターを使用するように Web サービスの sendport を変更し、そのテスト用の特定のプロパティを設定します。
次に、(おそらく) テスト ステップの設定に基づいてバインディング設定を生成し、シェル コマンドを実行してバインディングを更新するカスタム BizUnit ステップを作成することもできます。
これらすべてを実際に結び付けるために考慮したい最後のことは、メッセージの内容をテストする何らかの方法です。モック アダプターでこれを行うこともできますが、メッセージが大きい場合や、考えられる入力メッセージの範囲が広い場合は、すぐに面倒になります。
1 つのオプションは、受信したファイルを検証するためにSchematronを呼び出すカスタム パイプラインを作成することです。Schematron は、xsd よりもはるかに豊富なレベルのファイル インスペクションを可能にするスキーマ言語であるため、「要素 x にこのコンテンツが含まれている場合、要素 y が存在すると予想される」などを確認できます。
スキーマトロン スキーマをパラメーターとして使用するカスタム パイプラインを構築した場合、特定の単体テスト用のテスト ファイルをスワップインし、このテスト用にそれを検証することができます。Web サービスを呼び出すと、必要なものと実際に一致するファイルが得られます。 (そして xsd と一致するだけではありません)
BizUnitExtensions (www.codeplex.com/bizunitextensions) の共著者として、私は BizUnit の「ユニット」という名前が混乱を招く可能性があることに同意しますが、Biztalk では「統合テスト」がユニット テストです。一部の Biztalk 関係者は、モックを使用してパイプライン コンポーネントをテストし、その他のテスト ハーネス (+ BizUnit/Extensions) を使用してスキーマとマップをテストすることに成功しています。
残念ながら、オーケストレーションは不透明です。しかし、それには正当な理由があります。
(a) メッセージ ボックス内の巨大なサブスクリプション システム (オーケストレーションがアクティブ化されたときに使用するものなど) のため、オーケストレーションをホストする「仮想」プロセスを開始することはできません (これはパイプラインに対して実行できます。Tomas Restrepo は実行しました)。これらの線に沿ったもの）。
(b) また、この仮想プロセスは持続性と脱水をどのように処理しますか?. WF を使用している人がワークフローを完全にテストしようとすると、同じ問題が発生することは間違いありません。
(c) C# を直接操作しないため、モック インターフェイスをオーケストレーション コードに「注入」する方法はありません。
(d) オーケストレーションは実際には「ユニット」ではありません。複合要素です。ユニットは、メッセージ ボックスに出入りするメッセージと、式の形状を介して呼び出される外部コンポーネントです。したがって、モック Web サービス インターフェイスを注入できたとしても、モック メッセージ ボックスや相関セットなどを注入することはできません。
オーケストレーションのために実行できることの 1 つ (これを行うために BizUnitExtensions ライブラリへの追加を検討しています) は、OrchestrationProfiler ツールとリンクすることです。このツールは、すべての形状の非常に詳細なレポートを提供し、何らかの方法でその個人をチェックします。ステップが実行されました (およびおそらく実行にかかった時間)。これは、オーケストレーションをホワイト ボックスに近づけるのに非常に役立ちます。また、オーケストレーション デバッガーが多くの変数値を表示することを考慮すると、API を介してその情報を取得し、変数の値を表示することは確実に可能である必要があります。特定のインスタンスの特定の時点にいました。
リチャードの質問に戻ると、私の以前の開発チームには解決策がありました。基本的に、私たちが行ったことは、受信したサービス要求を解析し、事前設定された応答を返す、構成可能な汎用 HttpHandler を作成することでした。返される応答は、XPath などの条件に基づいて構成可能でした。BUILD および DEV バインディング ファイルでは、Web サービス エンドポイントはモックでした。これは、BUILD および DEV 環境を実際のサード パーティの Web サービスから分離する際に見事に機能しました。これは、私たちがモックを構築し、orch 開発者がそれを使用し、Web サービスの作成者が実際のサービスを構築するという「コントラクト ファースト」アプローチにも役立ちました。
[更新: 2009 年 2 月 17 日: このツールは現在 codeplex にあります: http://www.codeplex.com/mockingbird . このアプローチが興味深いと思われる場合は、チェックして、ツールについてどう思うか教えてください]
さて、誰かが古い "WHAT ABOUT MOCK OBJECT FRAMEWORKS" の栗を投げ入れる前に、上記のユーティリティが Biztalk の「消費者」と非 Biztalk の消費者の両方に使用されたと言っておきましょう。 CLR コンシューマーを作成するときにインターフェイスをモックし、期待を設定するための優れた方法です。(MoQ や TypeMock などについては近日中に検討する予定です)。ただし、上記の理由により、オーケストレーションでは機能しません。
お役に立てれば。
よろしく、
ベンジー
しないでください。
任意のインターフェイスに対してテストしないでください。また、それらのモックを作成しないでください。
ほとんどの人は、開発者 (ユニット) テストを、単一のクラスなどの重要な機能の個々のユニットをテストすることを目的としていると考えているようです。一方で、主要なサブシステムまたはシステム全体の顧客 (受け入れ/統合) テストを実行することも重要です。
Web サービスの場合、重要な機能単位は、通信配線の背後にある、意味のあるサービスを実際に実行するクラスに隠されています。これらのクラスには、その機能を検証する個別の開発者テスト クラスが必要ですが、Web サービス指向の通信配線はまったく必要ありません。当然のことですが、明らかにではないかもしれませんが、これは、機能の実装はワイヤリングの実装とは別にする必要があることを意味します。そのため、開発者 (単体) テストでは、そのような特別な通信配線がまったく見られないようにする必要があります。これは統合の一部であり、(適切に) 「ビジネス ロジック」ではなく「プレゼンテーション」の問題と見なすことができます。
顧客 (受け入れ/統合) テストは、より大規模な機能に対処する必要がありますが、「プレゼンテーション」の問題にはまだ焦点を当てていません。これは Facade パターンの使用が一般的である場所であり、統合された粗粒度のテスト可能なインターフェイスでサブシステムを公開します。ここでも、Web サービス通信の統合は無関係であり、個別に実装されます。
ただし、実際に Web サービス統合を含む別個のテスト セットを実装すると非常に便利です。ただし、その統合の片側だけをテストすることは強くお勧めしません。つまり、エンドツーエンドでテストしてください。つまり、実際の本番コードと同じように、Web サービス クライアントであるテストを構築します。実際のアプリケーションとまったく同じ方法で Web サービスを使用する必要があります。つまり、これらのテストは、そのようなアプリケーションを実装する必要がある人 (ライブラリを販売している場合の顧客など) の例として役立ちます。
それで、なぜそんなに面倒なことをするのですか？
開発者テストでは、アクセス方法に関係なく (すべてがビジネス ロジック層内にあるため、プレゼンテーション層とは関係なく) 機能が小規模で機能することを確認します。
顧客テストでは、ビジネス ロジック層のインターフェイス境界で、アクセス方法に関係なく、機能が大規模に機能することを確認します。
統合テストは、プレゼンテーション層がビジネス ロジック層と連携することを確認します。これは、基礎となる機能を無視できるようになったため (上記で個別にテストしたため)、管理可能になりました。言い換えれば、これらのテストは、きれいな顔 (GUI?) と通信インターフェイス (Web サービス?) の薄いレイヤーに焦点を当てています。
機能にアクセスする別の方法を追加する場合、その新しい形式のアクセス (プレゼンテーション層) の統合テストを追加するだけで済みます。開発者と顧客のテストにより、コア機能が変更されておらず、壊れていないことが保証されます。
Web サービス専用のテスト ツールなど、特別なツールは必要ありません。本番コードで使用するのとまったく同じように、本番コードで使用するツール/コンポーネント/ライブラリ/テクニックを使用します。これにより、他の人のツールをテストしていないので、テストがより意味のあるものになります。特別なツールを購入、展開、開発、保守する必要がないため、時間とお金を大幅に節約できます。ただし、GUI を使用してテストする場合 (そうしないでください!)、その部分には特別なツールが 1 つ必要になる場合があります (たとえば、HttpUnit?)。
それでは、具体的に説明しましょう。カフェテリアの日替わりメニューを追跡するための機能を提供したいとします (私たちのように、建物内に独自のカフェを持つ巨大企業で働いているため)。C# を対象としているとしましょう。
メニュー、メニュー項目、およびその他のきめ細かな機能とその関連データ用にいくつかの C# クラスを作成します。nUnit を使用して開発者テストを実行する nAnt を使用して自動ビルドを確立し (そうしますよね?)、毎日のメニューを作成して、これらすべての小さな部分からそれを確認できることを確認します。
私たちはどこに向かっているのかある程度わかっているので、細粒度の部分のほとんどを隠しながら、いくつかのメソッドを公開する単一のクラスを作成することで、Facade パターンを適用します。クライアントと同じように、その新しいファサードを介してのみ動作する顧客テストの別のセットを追加します。
ここで、巨大企業のナレッジ ワーカーが今日のカフェテリアのメニューをチェックできるように、Web ページを提供することにしました。ASP.NET ページを作成し、ファサード クラス (MVC を実行している場合はこれがモデルになります) を呼び出してデプロイします。すでに顧客テストを通じてファサード クラスを徹底的にテストしており、単一の Web ページは非常に単純であるため、Web ページに対して自動テストを作成することは控えます。数人のナレッジ ワーカーを使用した手動テストでうまくいきます。
その後、その日のランチを事前注文できるようにするなど、いくつかの主要な新機能の追加を開始します。既存のテストが既存の機能を壊さないように保護していることを知って、きめの細かいクラスと対応する開発者テストを拡張します。同様に、ファサード クラスを拡張し、インターフェースの成長に合わせて新しいクラス (MenuFacade や OrderFacade など) を分割し、顧客テストに同様の追加を行います。
さて、おそらく、Web サイトへの変更 (2 ページが Web サイトですよね?) により、手動テストは満足のいくものではなくなります。そこで、nUnit が Web ページをテストできるようにする HttpUnit に匹敵するシンプルなツールを導入しました。一連の統合/プレゼンテーション テストを実装しますが、ファサード クラスのモック バージョンに対して行います。これは、ここでのポイントは単に Web ページが機能することであるためです。ファサード クラスが機能することは既にわかっています。テストは、データが反対側に正常に送信されたことをテストするためだけに、モック ファサードを介してデータをプッシュおよびプルします。これ以上何もない。
もちろん、私たちの大成功により、CEO は Web アプリケーションを巨大企業の BlackBerry に公開するよう要求 (要求) するようになりました。そのため、いくつかの新しいページと一連の新しい統合テストを実装します。新しいコア機能を追加していないため、開発者または顧客のテストに触れる必要はありません。
最後に、CTO は、私たちのカフェテリア アプリケーションを巨大企業のすべてのロボット ワーカーに拡張するよう要求 (要求) しました。そこで、ファサードを介して通信する Web サービス層を追加します。繰り返しになりますが、コア機能、開発者テスト、顧客テストに変更はありません。同等の Web サービス API を使用してファサードを公開するクラスを作成することで Adapter/Wrapper パターンを適用し、その API を使用するクライアント側クラスを作成します。新しい一連の統合テストを追加しますが、それらは単純な nUnit を使用してクライアント側 API クラスを作成し、Web サービス ワイヤリングを介してサービス側 API クラスと通信し、モック ファサード クラスを呼び出し、ワイヤリングが機能することを確認します。
このプロセス全体を通して、本番プラットフォームとコード、選択した開発プラットフォーム、自動化されたビルドとテスト用のいくつかのオープンソース コンポーネント、およびいくつかの明確に定義された一連のテスト以外に、重要なものは何も必要ありませんでした。また、本番環境で使用しないものは何もテストしておらず、2 回もテストしていないことにも注意してください。
最終的に、機能のコア (ビジネス ロジック層) が成熟していることが証明されました (仮想的に)。デスクトップを対象とする Web サイト、BlackBerry を対象とする Web サイト、および Web サービス API の 3 つの個別のプレゼンテーション層の実装があります。
では、長い回答をお許しください。不十分な回答にはうんざりしており、提供したくありませんでした。そして、私が実際にこれを行ったことに注意してください（ただし、カフェテリアのメニューではありません）.
これはそれを行う方法です：
しかし、リチャードの質問に戻ると、私の前の開発チームには解決策がありました。基本的に、私たちが行ったことは、着信サービス要求を解析し、事前設定された応答を返す、汎用の構成可能なHttpHandlerを作成することでした。返送された応答は、XPathなどの条件に基づいて構成可能でした
しばらくこれを行う必要はありませんでしたが、Biztalk アプリをテストするときは、常に SOAP UI または Web サービス スタジオを使用していました。苦労せずにさまざまな入力値をテストできました。