Philosophy

Philosophy behind the framework

Mocking in the context of BizTalk server has been very demanding and controversial topic. There are unfortunately huge limitations imposed by how the product is built, which makes it almost impossible to even dream about the convenience that is brought by the utilization of mocking and patterns like IoC in the conventional development domain.

TransMock is not an exception to this, yet it attempts to bring us one step closer to a practical mocking approach for testing BizTalk server integrations. Its sole purpose is, as all the other mainstream mocking frameworks, to make it easier to author automated tests.

The framework builds on a very simple principle - mocking a target system's endpoint that an integration communicates is achieved by replacing the actual adapter employed for this communication with an adapter that allows to communicate with a BizUnit based test case instead. This allows for feeding messages from the BizUnit test case into the integration, as well as consuming messages from the integration back in the test case, where they can be validated against a set of expected results. Hence the name of the framework - Trans(port)Mock.

A simpler way to describe this principle is by an example from real life: The majority of the developers all around the world love pizza. So now and then you, as a developer, call the pizza guy and order a pizza, and soon it is delivered at your door and you enjoy consuming it either while working with the coolest piece of code or just watching some TV show. It would never cross your mind to return this warm, nice smelling and juicy pizza at your doorstep just because it was delivered with a Vespa and not with a Corvette, right? You are after all interested in the contents of the delivery, e.g. the pizza (as ordered of course), and not the details of how it was delivered!

This is exactly the situation with using TransMock - it utilizes a specialized adapter to deliver messages to and receive messages from BizTalk server in the context of a BizUnit test execution. So as long as the BizTalk integration receives/sends the exact same message (type, content, encoding) following the exact same message exchange pattern as expected from/to the source/destination system, it does not matter how this message was delivered!

This means that it will be possible to test the functionality of a BizTalk integration between multiple systems in a consistent and predictable manner, without the need of complex installations of test instances of those systems in specialized environments - the test can be executed right on the developer machine or on a build server. This would nevertheless result in cut in expenses for building and maintaining such test environments. Moreover it would cut back on the lead time for getting those environments up and running. Which on its turn would ultimately result in faster creation of automated tests, thus cutting dramatically on the overall testing effort, without jeopardizing, and hopefully improving, the quality of delivered BizTalk integrations.

This is not a groundbreaking approach - similar approach has been already used by the BizMock framework. However this framework has proven to be very hard to start using and has never taken off as the ultimate approach for such form of testing of BizTalk integrations.

One thing that would not be covered by performing tests with TransMock however is the correctness of the configuration of the actual transport to the actual source/target system. Considering the fact that these settings are often different for the different environments (considering the project has budget for such environments) the only effective way of testing those settings is by actually deploying the integrations to a given environment and verifying that the message flow between an integration and the source/target systems is actually taking place, by simply triggering such message flow. As for the use of a different adapter for performing the automated integration tests, it can be safely assumed that it can replace the actual adapters employed by the integration, as long as it implements the same functionality as any other BizTalk adapter, which are - receive messages with different encoding and format from the external world and retain those, and/or send messages to the external world by serializing them appropriately over the wire.

If you want to know more about the building blocks of TransMock please read What it consists of

If you want to know more about why using TransMock please read Why TransMock

If you are interested in getting your hands dirty right away please read the Getting started guide