Adding Automated tests is a critical part of
Some core tenants of good Integration Tests:
- They test outputs (service calls) for a given set of inputs
- They test different scenarios of input combinations
- They test error conditions
- They can be performed without requiring a database or another server to be set up “just so”.
- They mock outbound calls to control conditions and not make changes
Mocking HTTP
Mocking an HTTP requester endpoint is easy and very common in
<munit-tools:mock-when doc:name="Mock when" processor="http:request">
<munit-tools:with-attributes >
<munit-tools:with-attribute attributeName="path"
whereValue="/orders" />
</munit-tools:with-attributes>
<munit-tools:then-return >
<munit-tools:payload value="#[MunitTools::getResourceAsString('HTTPResponse.json')]" />
<munit-tools:attributes value="#[{'statusCode':200}]" />
</munit-tools:then-return>
</munit-tools:mock-when>
Creating an Munit SPY on the HTTP endpoint is the next step. Spying the endpoint allows the test to extract the data sent to the HTTP endpoint and test it for correctness. In the next snippet the data sent to the endpoint is checked for two things. First that it’s not null, and second that it has the correct “order number”. Field by field data checking is the preferred way.
<munit-tools:spy doc:name="Mock when" processor="http:request">
<munit-tools:with-attributes >
<munit-tools:with-attribute attributeName="path" whereValue="/orders" />
</munit-tools:with-attributes>
<munit-tools:before-call>
<set-variable value="#[output application/json --- payload]" variableName="origPayload" />
<logger message="Inside Narvar HTTP Call: #[payload]" level="INFO" doc:name="Logger" />
<munit-tools:assert-that expression="#[output application/java --- write(payload, 'application/json') as String]" is="#[MunitTools::notNullValue()]" />
<munit-tools:assert-that expression="#[output application/java --- vars.origPayload.order_info.order_number]" is="#[MunitTools::equalTo('99000055799')]" message="OrderNumber is not correct" />
</munit-tools:before-call>
</munit-tools:spy>
Mocking an External Database
Nearly all of my Mulesoft projects has a Database attached to it of some kind, so any good MUnit test will need to mock that server. Mulesoft has a bunch of directions on how to do this here: https://docs.mulesoft.com/munit/2.0/munit-database-server
I’m not going to replicate directions that are contained in the above link, since it will be better at it than I, but I will make some suggestions:
- Go into your Database GUI, like MySQL Workbench and export a few lines of your database tables into a CSV file, or heck, export them all, but what really matters most is your headings on the table.
- Make sure your Database Name in the mock, “Database”, matches your Schema name of the DB you’re using.
- Make sure the file name matches the table name you are using.
- It seems the directions on requiring the test to “Start the Server” in the before test place are incorrect. The server is already started.
<dbserver:config name="MUnit_DB_Server_Config" doc:name="MUnit DB Server Config" >
<dbserver:connection csv="my-database-table.csv" database="MulesoftESB" connectionStringParameters="MODE=MySQL" />
</dbserver:config>
Once the database is instantiated you can do all the regular database calls you would, and then also verify in
Mocking and Spying SQS
In the next bit of code I’m both Mocking SQS, and then SPYing the payload send to SQS for correctness.
<munit:behavior>
<munit-tools:mock-when doc:name="Mock when" processor="sqs:send-message">
<munit-tools:with-attributes>
<munit-tools:with-attribute attributeName="queueUrl" whereValue="${sqs.orderscreatequeue}" />
</munit-tools:with-attributes>
<munit-tools:then-return>
<munit-tools:payload value="#[output application/json --- payload]" mediaType="application/json" />
</munit-tools:then-return>
</munit-tools:mock-when>
<munit-tools:spy doc:name="SQS-Spy" processor="sqs:send-message">
<munit-tools:with-attributes>
<munit-tools:with-attribute attributeName="queueUrl" whereValue="${sqs.orderscreatequeue}" />
</munit-tools:with-attributes>
<munit-tools:before-call>
<set-variable value="#[output application/json --- read(payload.body)]" doc:name="Set Variable" variableName="origPayload" />
<munit-tools:assert-that expression="#[output application/java --- write(payload, 'application/json') as String]"
is="#[MunitTools::notNullValue()]" />
<munit-tools:assert-that expression="#[output application/java --- vars.origPayload.items[0].description]" is="#[MunitTools::equalTo('Levi\'s (R) 550 (TM) Relaxed Jeans')]" message="Ordered Item Description is not correct" />
</munit-tools:before-call>
</munit-tools:spy>
</munit:behavior>
SQS has some of it’s own idiosyncrasies regarding the data model. That’s a different blog post entirely.
Good luck Muniting!!
Recent Comments