2

BizTalk を使用して、呼び出し可能なオーケストレーション (パイプラインなし) を他のオーケストレーションのサービスとして使用し、アーキテクチャの柔軟性を高めています。しかし、それらの単体テストはかなり悪質です。現在、単体テストの前に BizTalk に展開するラッパー オーケストレーション (テストするためにオーケストレーションを呼び出すだけ) を備えた別のアプリケーションを使用しています。

誰かが呼び出し可能なオーケストレーションを単体テストするためのより良い方法を持っていますか? 最も望ましいのは、追加のアーティファクトをデプロイする必要がない単体テストを行うことです。

前もって感謝します。

4

1 に答える 1

0

オープンな質問にNOで答えるのは難しいですが、私の答えは、それは実際には不可能だということです。

オーケストレーションは、BizTalk オーケストレーション エンジンと非常に緊密に結合されています。オーケストレーションを単体テストする場合は、そのオーケストレーション エンジンをシミュレートする必要があります。それは簡単な仕事ではありません。脱水、シリアル化、スコープ、オーケストレーションとの間のメッセージングが実際にどのように機能するかなど、考えなければならない詳細がたくさんあります。

オーケストレーションの一部を分離し、物理ポートに直接バインドしないようにすることで、正しい手順を実行していると言えます。これにより、テストが可能/簡単になります。接続が少ないということは、エラーポイントが少ないことも意味します。

あなたが行うオーケストレーション作業の量を制限しようと思います。オーケストレーションは、より良い (または少なくともよりテスト可能な) 代替手段がない場合にのみ使用してください。

展開し、メッセージをドロップし、結果を確認するだけで、オーケストレーションを迅速かつ労力をかけずにテストできる場合は、BizTalk 開発者のスイート全体よりも多くのテストを既に行っていることになります。このプロセスを簡単にし、可能な限り自動化 (デプロイ、ファイルのドロップ、予想される出力の確認) を行えば、少なくともリグレッションの検出が容易になります。

目標は、テストを非常に簡単/安価で信頼性が高く、テストしないよりも簡単にテストできるようにすることです。そうすれば、マネージャーが言うのを防ぐことができますskip the tests, they take too long。あなたは彼らに尋ねてもらいたいでしょう:can you test it first?

于 2015-09-21T16:16:54.327 に答える