2

BizTalk アプリケーションの自動システム テストを作成していますが、テストの検証をいつ実行できるかを判断するのに問題があります。検証の前に、BizTalk がメッセージを完全に処理したか、メッセージ処理がタイムアウトしたことを確認する必要があります。

[Test]
public void ReceiveValidTaskMessageTestShouldBeLoggedInMessageLog()
{
    // Exercise            
    MsmqHelpers.SendMessage(InboundQueueName, ValidMessage);

    // Verify
    Assert.That(() => GetMessageCount("ReceiveError"), Is.EqualTo(0).After(1000));
    Assert.That(() => GetMessageCount("Receive"), Is.EqualTo(1).After(1000));
}

最後の 2 行は、SQL サーバーのテーブルにメッセージのコピーが存在するかどうかをチェックします。1 つのテーブルは成功したメッセージ用で、もう 1 つのテーブルはエラー用です。

ここでの問題は、メッセージを送信した直後に、エラー テーブルにメッセージが配置されていないことを確認することです。ただし、BizTalk がまだメッセージを処理していない場合、そのアサーションは失敗する必要があっても成功します。

必要なのは次のようなものです。

[Test]
public void ReceiveValidTaskMessageTestShouldBeLoggedInMessageLog()
{
    // Exercise            
    MsmqHelpers.SendMessage(InboundQueueName, ValidMessage);

    // Verify
    Assert.That(() => PendingMessages, Is.EqualTo(0).After(1000));
    Assert.That(() => GetMessageCount("ReceiveError"), Is.EqualTo(0));
    Assert.That(() => GetMessageCount("Receive"), Is.EqualTo(1));
}
4

2 に答える 2

1

ここに、自動化された統合テストの問題があります。

このようなテストは証拠に基づいており、テストのアサーションに反映されます。データベースをチェックして、処理が行われたという証拠を探しています。

同様に、処理が終了したことを知るために、これが発生したという何らかの証拠を探しています。たとえば、理論的には、BizTalk メッセージ ボックス データベースに対してクエリを実行して、内部の状態を確認できます。

ただし、BizTalk はテストを念頭に置いて構築されていないため (弱点の 1 つ)、この種の調査には適していません。私は確かにこれを行う方法を知りません。

検討する価値のあるいくつかのアプローチ:

  1. BizTalk がメッセージの処理を完了できるように、データベース チェックを実行する前に "妥当な" 時間待ちます。
  2. データベースをチェックする前に、処理が完了する直前に BizTalk がログ ファイル (またはその他の証拠) を出力するようにします。

アプローチは限られていますが、自動化された統合テストは非常に価値があります。

于 2012-06-26T15:52:27.843 に答える
0

より良いアプローチは、レコードがこれらのテーブルのいずれかに表示されたときに通知され、必要に応じてテストに合格/不合格になることです。基本的な無限ループを使用してテーブルを継続的にポーリングするか、より洗練されたソリューションとしてイベントを使用することができます。詳細については、イベント ハンドラー デリゲートを参照してください。

于 2012-06-28T09:09:58.457 に答える