3.1.20. How to Execute a Request Unit Test (Sending Synchronous Message)

For information on how to execute a request unit test, see How to Execute a Request Unit Test (Sending Synchronous Message Process).

However, “send queue” and “receive queue” should be read as “communication destination”.

In this section, the differences with How to Execute a Request Unit Test (Sending Synchronous Message Process).

3.1.20.1. How to write test data

3.1.20.1.1. An example of the expected value of a request message when a message is sent once and the response message (response message) that is returned

The following is an example of the description of a response message that is returned when a message is sent once.

../../../../../../_images/http_send_sync_response.png

Tip

RESPONSE_BODY_MESSAGES (and EXPECTED_REQUEST_BODY_MESSAGES used in the examples below) can be described by dividing into multiple fields.

When a string is long and cannot be read if written in one cell, the string is divided and written.

When dividing, “field name” can be an arbitrary string. In the above example, XML1, XML2 and XML3 is used.

The following is a description example of the expected value of a request message that is returned when a message is sent once.

../../../../../../_images/http_send_sync_expected.png

Tip

When using JSON or XML data format, only one test case should be written in one Excel sheet.

This is due to the limitation of NTF, which expects the string length of each Excel line to be the same for the message body. In JSON and XML data formats, the request message length is generally different for each request, so only one test case can be described in practice.

3.1.20.1.2. An example of the expected value of a request message when a message is sent more than once and the response message (response message) that is returned

When sending a message multiple times, the test should be written with attention to the following specifications of the testing framework.

The following is a description example of the response message that is returned when the message is sent multiple times.

../../../../../../_images/http_send_sync_ok_pattern_response.png

The following is a description example of the expected value of a request message that is returned when a message is sent multiple times.

../../../../../../_images/http_send_sync_ok_pattern_expected.png

Tip

If there are multiple request IDs to be sent, testing the order is not possible. In the above example, the test is successful even if ProjectSaveMessage2 is sent before ProjectSaveMessage.

3.1.20.1.2.1. Failure pattern test

The failure pattern can be tested by configuring a specific value starting with “errorMode:” in the table of the response message.[1]

The correspondence between the configuration values and failure pattern tests is shown below.

Value to be configured for the first field Failure description Operation of the automated test framework
errorMode:timeout Test if timeout error occurs while sending the message Throws HttpMessagingTimeoutException (subclass of MessagingException) [2]
errorMode:msgException Test when a message send and receive error occurs Throws MessagingException

This value should be in the first field, excluding “no”, in both the header and the body of the table in the response message.

[1]If the business action does not explicitly control MessagingException, there is no need to perform fault testing in individual request unit tests.
[2]It throws out a different class than How to Execute a Request Unit Test (Sending Synchronous Message Process).

3.1.20.1.3. Description for using the mockup

Configure expectedMessageByClient in testShots and group ID in responseMessageByClient. For information on mockup, see How to Perform a Subfunction Unit Test with Sending Synchronous Message Process.

The relevance of group IDs is the same as for expectedMessage and responseMessage in How to Execute a Request Unit Test (Sending Synchronous Message Process), and is therefore omitted.

../../../../../../_images/http_send_sync_shot.png
If sending synchronous messages by MOM and HTTP sending synchronous message take place simultaneously in the same action,
the group ID used in the sending synchronous message process by MOM is configured to “expectedMessage” and “responseMessage”,
and the group ID used in the HTTP sending synchronous message process is configured to
“expectedMessageByClient” and “responseMessageByClient” respectively.
../../../../../../_images/http_mom_send_sync_shot.png

Tip

The Group ID should be configured to a different value in the sending synchronous message process by MOM and HTTP sending synchronous message process. Note that if the same group ID is specified, the result verification will not be performed correctly.

3.1.20.1.4. Asserting the request message

The value of the file-type set in the directive line of the test data changes the way in which the request message is asserted.

For details on how to configure and the assert details, refer to response message section of How to Execute a Request Unit Test (Receiving Synchronous Message Process).

3.1.20.2. Configuring the classes to be used in the framework

Usually, the classes are configured by the architect and do not need to be set by the application programmer.

3.1.20.2.1. Mockup class configuration

Configure mockup class to be used in request unit test in the component configuration file.

<!-- Client for HTTP communication -->
<component name="defaultMessageSenderClient"
           class="nablarch.test.core.messaging.RequestTestingMessagingClient">
  <property name="charset" value="Shift-JIS"/>
</component>

The character code output to the log can be changed by specifying the character code name in the charset field. Normally character code is optional, and UTF-8 will be used if omitted.