This project is read-only.

Mocking dynamic send ports

Mocking dynamic send ports with TransMock requires some code changes to the orchestrations that are utilising such ports. Luckily TransMock supplies a helper class that takes care of most of these changes and thus limiting them to a bare minimum. The helper class is called MockHelper and resides in the TransMock.TestUtils.BizTalk assembly. This assembly is to be found under the [TransMock installation folder]\Ext folder. Make sure that you add a reference to this assembly in your orchestrations project.
This class exposes 2 static methods with the following signitures:

    MockDynamicSendPort(string portName, XLANGMessage outboundMessage), 
   and
    MockDynamicSendPort(string portName, string customBehaviorConfig, 
        XLANGMessage outboundMessage)


The former method mocks a dynamic send port with the provided logical port name, as defined in the orchestration, by setting the necessary message context properties up for the mock adapter to work properly. The latter method does the same thing, but in addition it adds any specific custom behaviour configuration that is used by the original port transport. This method is applicable only in the cases where the original adapter used in the dynamic send port is a WCF one.

Both methods return an instance of the class MockTransportConfig which has 2 properties - TransportType and Address. These properties are used for setting the corresponding properties on the dynamic send port itself. The transport type property always returns WCF-Custom, while the Address property returns the properly formatted address for the mock endpoint that the dynamic send port would communicate with during test execution.

It is very important to note the these methods mock a specified dynamic send port only in the case when a test case utilizing TransMock is being executed! In the case of normal operation the methods would simply return null which will be an indication that the original adapter configuration should be applied. This way the code change for mocking a dynamic send port will be implemented only once and then it will cater for both the normal scenarios as well as the test scenarios.

The code snippets below show what the code change would actually boil down two:
Assuming that we have a logical dynamic send port called POProcurementOutPort, an outbound message named POProcurementMsg and a variable of type MockTransportConfig called mockConfig, the code for mocking this port would look like this:

    mockConfig = TransMock.TestUtils.BizTalk.MockHelper.MockDynamicSendPort("POProcurementOutPort",POProcurementMsg);

This code should be placed within a construct message shape where the outbound message is being constructed.
In an expression shape which follows the construction shape the code for configuring the Address and TransportType properties on the port. This code looks like this:

    if(mockConfig != null){
	POProcurementOutPort(Microsoft.XLANGs.BaseTypes.Address) = mockConfig.Address;
	POProcurementOutPort(Microsoft.XLANGs.BaseTypes.TransportType) = mockConfig.TransportType;
    }
    else{
	//place here the logic for setting up the context properties for the original adapter
    }


Finally you have to mark all the dynamic send ports defined in the bindings file with the Mock tag so that the Mockifier would mock them accordingly and include them in the *MockAddresses class file. The Mock tag should be define as shown in the snippet below:

    <SendPort Name="SomeSendPortName" IsStatic="False" ….>
	<!-- <Mock /> --->
	…
    </SendPort>


Please note that it is a requirement for the Mockifier to have the Mock tag right under the SendPort tag.

Once all this is done and you have deployed the application you can write the test cases for it. In your test project do the following:
1. Add a reference to the TransMock.Integration.BizUnit project, if not added already.
2. Add a new test class, alternatively continue adding test methods to an existing class.
3. Include the generated *MockAddresses class if not done so already.
4. Add/Update the method for test class initialization by adding the following line:
		TransMockExecutionBeacon.Start()

5. Add/Update the method for test class cleanup by adding the following line:
		TransMockExecutionBeacon.Stop()


With this the plumbing for creating test cases that include testing of dynamic send ports is completed. The TransMockExecutionBeacon class is used to notify the MockHelper that a test case with TransMock is actually being executed. It works in a way that it creates a special named pipe with a distinct path and when the MockHelper methods are being executed from within an orchestration instance, they try to connect to this pipe. Successful connection is treated as if the orchestration is executing as part of a TransMock test case and hence mocking will be applied. Otherwise the helper methods will simply return null.

For writing the actual test cases, whenever you would like to receive a message from a dynamic send port you have to set the URL property of the corresponding test step to the address property from the *MockAddresses class corresponding to the same dynamic send port. These properties are named in a special way, which differs from the ones for static ports - Dynamic<Logical dynamic port name>. From the example above the corresponding property in the *MockAddresses class would be named DynamicPOProcurementOutPort. The remaining part of authoring test cases for dynamic send ports is exactly the same as any other TransMock test case. It is important to note that you have to use the matching BizUnit test step type for the given message exchange pattern - if you have a one-way dynamic send port you have to use the MockReceiveStep, and for the case with solicit-response dynamic send port you have to use the MockRequestResponseStep.

Last edited Dec 7, 2014 at 8:47 PM by cyberbyber, version 2