This neat little framework allows you to fasttrack your testing experience of BizTalk server integrations to new hights without the hustle of setting up complex test environments incurring extra cost for hardware and test system licenses. You simply author tests with BizUnit by utilizing 4 custom mock test steps which allows you to test any thinkable messaging scenario to and from your integrations. And all that is executed on your developer box and/or on the build server, allowing you to very quickly boost the quality of the integrations by testing those much earlier than waiting to deploy to a system test environment.

Now it is even easier to install TransMock. Simply add the NuGet package TransMock.Framework to your test project like this from the NPM console in Visual Studio:

Install-Package TransMock.Framework

This will automatically install the TransMock BizTalk adapter and BizUnit 5.0 packages (if not installed already).

Note: If you have previos version of TransMock installed on your box/build server make sure you uninstall it first through Control panel/Programs and features.

Note: Installation of the adapter requires adminsitrator previliges in order to GAC the related assemblies. If you are running NuGet package restore on the build server you might see that these actions fail. Fear not - just make sure the first time this happesn (for each version) you GAC manually the 2 assemblies of the adapter - TransMock.Wcf.Adapter.dll and TransMock.Communication.NamedPipes.dll. Alternatively you can try to force the nuget.exe to be executed with admin account context during the build.

In the cases where testing of communication over dynamic send ports is required you should add the TransMock.TestUtils package to your orchestrations project as follows:

Install-Package TransMock.TestUtils

• Introduces new programming model
• Adds intellisense capabilities
• Still supports BizUnit programming model
• Few refactorings and bug fixes

The new programming model of TransMock aims to bring fresher, fluid based syntax as with other modern mocking frameworks, emphasazing on the message exchanged between a tested integration/service and the test case while empowering the developer to perform all verifications in place of the test method. The intended outcome of all this is a more compact and easy to both author and maintain test code base. The 2 main classes that represent the new programming model are EndpointsMock and TestMessagingClient. The former represents the mocked endpoints of the integration/service that the test will run against, while the latter represents a messaging client will be send and receive mock messages and will perform verification upon reception. TAddreses is set as the type of the *MockAddresses class as generated by the mockifier. A test with the new programming model consists of 2 parts - first create an endpoint mock instance and then get the test messaging client for the mock and start sending/receiving messages.

// Setting up a mock instance
var serviceMock = new EndpointsMock<MyServiceMockAddresses>();

// Seting up a one-way receive endpoint
serviceMock.SetupReceive(ep => ep.ReceivePO); // ep is an instance of MyServiceMockAddresses and ReceivePO is the address for a corresponding one-way receive endpoint

// Setting up a one-way send endpoint
serviceMock.SetupSend(ep => ep.SendPO);

// Setting up a two-way receive endpoint
serviceMock.SetupReceiveRequestAndSendResponse(ep => ep.POService);

// Setting up a two-way send endpoint
serviceMock.SetupSendRequestAndReceiveResponse(ep => ep.OrderValidationService);

The above snippet can be written with method chaining style:

// Fluidness of TransMock
serviceMock.SetupReceive(ep => ep.ReceivePO)
    .SetupSend(ep => ep.SendPO)
	.SetupReceiveRequestAndSendResponse(ep => ep.POService)
	.SetupSendRequestAndReceiveResponse(ep => ep.OrderValidationService);

Once the mock isntance is set up we can proceed with sending messages to and receiving messages from the integration/service in order to conduct a test:

// Getting hold of the test messaging client instance
var testMessanger = serviceMock.CreateMessagingClient(); // This is the only way to instantiate a TestMessagingClient.

// Sending a message to a one-way receive endpoint
testMessanger.Send(rp => rp.ReceivePO, "Request.xml");

// Receiving and verifying a message from a one-way send endpoint
testMessanger.Receive(sp => sp.SendPO,
    v => ValidatePOResponse(v)); // v is of type ValidatableMessageReception and has 2 properties - Index and Message. ValidatePOResponse is a custom method and validates the supplied parameters according to specific expectations for this particular operation

// Sending a message to a 2-way receive endpoint and expecting a syncrhonous response
testMessanger.SendRequestAndReceiveResponse(rp => rp.POService,
    "POServiceRequest.xml", 
	responseValidator: rv => ValidatePOResponse(rv)); // Verifies the received request

// Receiving a message from a 2-way send endpoint and sending a syncrhonous response back
testMessanger.ReceiveRequestAndSendResponse(rp => rp.OrderValidationService,
    responseSelector: rs => new StaticFileResponseSelector{ FilePath = "OrderServiceResponse.xml"}, // This expression sets the response from a static file
	requestValidator: rv => ValidateOrderRequest(rv)); // Verifies the received request.

As you can see in only few lines of code one is capable of both interacating with the tested integration/service and perform in-place validation of the messages received from it. The above invocations can be easily chained as well.

Important prerequisite for producing the correct variant of the *MockAddresses helper class is to set the following property in your *.btdfproj file (in case you utilize BTDF) with the given value:

...
<TransMockProgModel>New</TransMockProgModel>
...

This was introduced in order to maintain backward compatibility when generating the *MockAddresses class as the new style of this class is considered a breaking change. The default behaviour of the mockifier when invoked from BTDF is to generate a *MockAddresses class with string properties only, which is referred as Legacy. In case you invoke the mockifier in a different way without BTDF then you do not have to do anything in order to start using the new programming model and new style of *MockAddresses generated class. However in order to maintain backward compatibility for your existing tests you need to add the new -l switch at the line where the mockifier is invoked. Otherwise you risk that all your *MockAddresses classes will be generated accroding to the new style and then the tests that depend on those will start failing.

Blog articles For version 1.5

• Introducing the new programming model of TransMock

For versions prior to 1.5

• Testing a real world BizTalk integration with TransMock - part 1
• Testing a real world BizTalk integration with TransMock - part 2
• Testing a real world BizTalk integration with TransMock - part 3

• Now supports BizTalk Server 2016
• Available through Nuget
• Now supports BizUnit 5