At my current client we have taken a keen interest in the BizUnit functionality that Kevin Smith worked on. However, although a lot of the work was useful we wanted to take the concept a little further and create a more complete Test Harness that could be used by more than just developers conducting Unit Testing.
Our Integration Services platform that is currently based on BizTalk 2004 is providing a service to the various departments within the company. The concept of providing a service necessitated a requirement to provide a relatively simple and common framework to conduct the initial and regression testing for applications that were to be hosted on the platform. An environment could be hosting any number of applications and the process of post deployment testing could become quite complicated and messy.
NUnit is also being integrated more thoroughly at the client’s site so that it potentially could be a company standard. Therefore, when we discovered the work Kevin had been doing we thought it would be an ideal starting point for our requirements.
The first modifications we made were to simplify the configuration XML so that both application developers who may not be quite as familiar with BizTalk or the underlying BizUnit design as they should be (this is the real World after all) and Testers could create and verify easily.
In addition to this, a code generation utility was developed to interrogate the configuration XML and create the assembly required by NUnit, thereby reducing the dependency on developers further. So a Tester could simply create an XML configuration file, use the utility and have a readily available Unit Test ready to execute. During this build process the configuration files are now validated against a schema, thereby reducing the likelihood of the introduction of bugs through the configuration file itself.
We have also spent some time introducing a variety of test case steps that were not initially provided and also updated some of those that existed. An example being the HTTP Post Step can now submit a message multiple times using threading.
But perhaps the biggest requirement was to make the framework capable of imitating a number of messaging patterns that were identified. We wanted to utilise NUnit to also provide a mechanism for longer running tests, not simply to execute a simple functional test. So, you may have an orchestration that has a number of inputs and outputs whereby it communicates with various external applications. We wanted to enable the framework to cater for this and mimic those scenarios.
Therefore, we had to write some extra components to handle this functionality, in particular a stub that would mimic the external application. This remoting component is hosted within IIS and exposes events to which the updated BizUnit utility can subscribe.
So, BizUnit can send a message using the HTTP Step to a receive location, this receive location in turn uses CBR to route the message to the send port, which in turn submits the message to this “application”. The application then raises an event to inform any subscribers that a message has been received, so the BizUnit Test Case that has an HTTP Receive step after the post is made aware that the message was received by the “application”.
Now that this fundamental concept is working the next step is to implement some more improvements. Obviously if you are to be submitting multiple messages through BizUnit in this way and wish to handle the receive functionality a correlation between the two will need to be implemented. This could consist of defining a correlation element within the configuration file and then using a temporary repository to store each correlation identifier as it is submitted and removing from the repository when received.
Also, it would be useful to implement a transformation mechanism so that the “application” can return different XML. This way, you can mimic a call out to an application from an orchestration that requests some form of approval for example.
In conclusion, we may be using NUnit to do something that it was not really originally intended for, but it has proven to be sufficiently extensible to handle the tasks that we wanted to implement. It has provided a simple, yet familiar interface for users to conduct both unit testing and some form of regression testing. There may in future be a requirement to execute steps asynchronously or implement the tests in such a way to achieve this, but I will leave that to a later date.