5

フローごとに約 5 つのコンポーネントを持つ 6 つまたは 7 つのフローを持つ Mule アプリケーションがあります。これがセットアップです。JMS リクエストを ActiveMQ キューに送信します。ミュールはそれを聞きます。メッセージの内容に基づいて、対応するフローに転送します。

 <flow name="MyAPPAutomationFlow" doc:name="MyAPPAutomationFlow">
      <composite-source>
            <jms:inbound-endpoint queue="MyAPPOrderQ" connector-ref="Active_MQ_1" doc:name="AMQ1 Inbound Endpoint"/>
            <jms:inbound-endpoint queue="MyAPPOrderQ" connector-ref="Active_MQ_2" doc:name="AMQ2 Inbound Endpoint"/>
      </composite-source>
        <choice doc:name="Choice">
            <when expression="payload.getProcessOrder().getOrderType().toString().equals(&quot;ANC&quot;)" evaluator="groovy">
                <processor-chain>
                    <flow-ref name="ProcessOneFLow" doc:name="Go to ProcessOneFLow"/>
                </processor-chain>
            </when>
            <when....
            ...........


         </choice>
    </flow>


 <flow name="ProcessOneFLow" doc:name="ProcessOneFLow">
        <vm:inbound-endpoint exchange-pattern="one-way" path="ProcessOneFLow" responseTimeout="10000" mimeType="text/xml" doc:name="New Process Order"/>
        <component doc:name="Create A">
            <spring-object bean="createA"/>
        </component>
        <component doc:name="Create B">
            <spring-object bean="createB"/>
        </component>
        <component doc:name="Create C">
            <spring-object bean="createC"/>
        </component>
        <component doc:name="Create D">
            <spring-object bean="createD"/>
        </component>    
</flow>


 <spring:beans>

    <spring:import resource="classpath:spring/service.xml"/>
    <spring:bean id="createA" name="createA" class="my.app.components.CreateAService"/>
    <spring:bean id="createB" name="createB" class="my.app.components.CreateBService"/>
    <spring:bean id="createC"  name="createC" class="my.app.components.CreateCService"/>
    <spring:bean id="createD" name="createD" class="my.app.components.CreateDService"/>
            ......
            ......
 </spring:beans>

今、それらを使って機能テストを作成する方法がわかりません。

Mule の Web サイトで Functional Testing のドキュメントを調べましたが、非常に単純なテストがあります。

機能テストは、DAO またはサービス レイヤーを使用して実際のバックエンドの更新を行うことは想定されていませんか、それともサービス レイヤーをモックアップする単体テストの拡張にすぎませんか?

私はアイデアを思いつきました-リクエストを受け取り、インメモリMuleサーバーを使用して、フロー内の1つのコンポーネントから別のコンポーネントにリクエスト-レスポンスを渡すことができます。また、フローのほとんどは Fire and Forget タイプのフローであり、ステータスの更新はコンポーネントが行う DB の更新によって管理されるため、どのフローにもアウトバウンド エンドポイントがないことに注意してください。

また、なぜテスト用に個別の Mule 構成 xml ファイルを作成する必要があるのですか? 実際に Live にデプロイされるフロー xml をテストしていない場合、このテストのポイントは何ですか? テストのためだけに個別のxml構成を作成しているため、目的が多少損なわれます...専門家がもう少し詳しく説明し、使用しているものと同様のテスト例を指摘してください。

PS: Mule 内のコンポーネントは、Web サービスやデータベースなどの外部システムに依存しています。機能テストでは、それらを実行する必要がありますか?それとも、これらのサービス/Db アクセスをモックアウトする必要がありますか?

4

2 に答える 2

3

Mule アプリケーションの機能テストは、データベースや JMS ブローカーなどの外部リソースに依存するアプリケーションのテストと同じであるため、標準アプリケーションで行うのと同じ手法を使用する必要があります。

通常、これは、データベース用の HSQLDB や JMS 用の一時的な ActiveMQ インメモリ ブローカーなどのインメモリ実装でリソースをスタブ化することを意味します。Mule アプリケーションの場合、これは構成をモジュール化して、「ライブ」トランスポートが別のファイルで定義されるようにすることを意味します。このファイルは、テスト時にメモリ内バリアントを含むファイルに置き換えます。

Mule がリソースと正しく対話したことを検証するには、Java クライアント (JDBC や JMS など) を使用してリソースを直接読み取ることができます。これは、純粋に Mule 以外のクライアントが Mule の読み取りに問題がないことを確認する場合に適しています。または、MuleClient を使用してこれらのリソースから読み取るか、これらのリソースを消費してメッセージを に渡すフローを作成します<test:component>。

参考までに、これらのさまざまな手法については、 Mule in Action, second editionの第 12 章で説明および実演されています。

于 2012-11-29T16:52:49.070 に答える