BizTalk Testing Guidance – Dealing with external systems/dependancies

Article source: http://geekswithblogs.net/michaelstephenson

When we are testing our BizTalk solution one of the biggest challenges is how we deal with the dependency on external systems. Some of the common scenarios I have come across are as follows:

1. We will be integrating with some web services but there are no test instances of these services we can use
2. We will integrate with a LOB application but there is either no test instance of the LOB system of using the LOB application will make it difficult to perform a lot of our testing
3. We are working on a larger project and the system we will be integrating with does not yet exist or is in early development and is changing a lot
4. I’m working with a B2B partner and they can not support my testing

These problems are typical on most projects and are one of the common excuses for poor testing and a resulting low quality solution. In this article I will discuss some of the approaches we take to dealing with these problems.

Probably one of the key things here is that if you are working with BizTalk or some kind of services solution you will hopefully be thinking carefully about a contract first approach. By using a contract first approach you will understand the messages you will be passing between you and external systems and at least how your solution will react to different messages it receives. With this understanding you should be able to use various techniques to simulate how an external system will work in your solution.

Obviously there is a trade off because you don’t want to recreate the whole external application but if you can mimic the communication protocol and replicate some of the messaging exchanges that will be involved in some of your testing scenarios then you can make significant improvements in the testing you can do.

Use a Mocking Framework

For completeness I will mention the use of mocking frameworks such as Rhino Mocks. While these frameworks are good and offer a lot of value in the testing of some aspects of BizTalk solutions I think when it comes to BizUnit style testing of an end to end process they don’t really help you.

I usually use something like Rhino Mocks to test a custom .net component, pipeline component or possibly a custom adapter. I have mentioned these in previous posts in the testing series.

I will later in this article discuss a community project called BizMock which I feel is slightly different to NMock and Rhino Mocks.

Creating a Stub

One of the simplest ways you can replicate the external system is by creating a simple stub of that system. One of the most common ways to do this if it is a web services enabled application is to create a Visual studio web services project in your solution and then add some web services and web methods that match the external web service. I generate a server side stub of the web service and then add some logic to the generated method to make it meet the test cases. Often the stub will implement some logic to return different responses based on a parameter in the inbound request message or do a different action.

I will provide a couple of follow-up articles to show how we normally create stubs for asmx web services and WCF services.

I have made a list of what I think are some of the main good and bad points about this approach:

I have an example of a situation where a stub approach really made our life easier. In a project we were developing a web service fa%u00e7ade on top of the API for the Cognos Reporting system. The intention was to provide a flexible service which applications could call to execute a report in Cognos and the service would encapsulate all of the logic required to execute the report.

The Cognos API is a large assembly which allows you to do a lot of different things against Cognos. One of these things is to execute a report. The report execution is slightly complex and to get good coverage of our code was going to be slightly difficult. One of the challenges was that we would need an instance of Cognos to be able to connect to. This would be a pain as there were a lot of Cognos projects going on and getting on of their boxes with a set of suitable test reports which they could maintain wouldn’t really work because as soon as there is a conflict between team priorities someone is going to be affected by this coupling.

We considered having a local instance of Cognos to support our development/build/test effort but straightaway this requires our team to have a Cognos skill set.

With a little bit of investigation we worked out that the Cognos API used to send HTTP traffic between itself and the Cognos server so we were able to capture some of this traffic and to use this to simulate the HTTP calls so we could then create a .net Web Application which used an aspx page to receive and send the appropriate messages to allow the Cognos client side API to work. The benefits of this stub were:

• We didn’t need to depend on a Cognos installation for all of our development effort
• We were able to test parts of the code which we couldn’t without working out how to break Cognos from our test case
• We didn’t need to create any test reports
• We didn’t need any Cognos skill

This was probably one of the more extreme cases of stubbing out an application. We had initially depended on a Cognos instance but we found that our Continuous Integration builds would constantly break because someone deleted our reports etc.

Using Mocking Bird

Mocking Bird is a codeplex project that was introduced to me by Santosh Benjamin. It is something I haven’t used in anger but it’s been on my radar for a while. Basically the project provides a pattern to allow you to implement stubs to simulate external systems. This project can simulate traditional web services and WCF services.

I think it will save you some of the effort of creating and maintaining the stubs discussed above.

Santosh has some good articles about Mocking Bird and I would recommend looking into it. Probably the one key area where it will not help is if your external application is not supported by WCF/Web services. In this scenario you can just drop back to the above stub approach and code something to simulate that system.

For more info refer to: http://www.codeplex.com/mockingbird

Using Alternative Bindings

I was providing some advice to a project once and they were doing some integration with Dynamics AX (I think). Anyway for whatever reason they could not integrate with web services and were using the BizTalk AIF Adapter for Dynamics AX. One of the dependencies of the adapter was that you needed a build and ready deployment of Dynamics AX for the adapter to work with.

On the project at the same time that the BizTalk team were developing an EAI solution, a Dynamics team were also working hard on the Dynamics part of the project. This means that this coupling would cause problems with the BizTalk team not being able to test against Dynamics and it being difficult to stub out the LOB application due to the complexity of the adapter.

One of the advantages of BizTalk is that because you have loose coupling between an orchestration and any ports it uses the BizTalk team in this scenario were able to change their approach to testing in their development environment and use different bindings to change the communication protocol to talk to a stub which was created to simulate the behaviour of Dynamics but it would use a different communication mechanism.

By looking at the message exchange patterns the BizTalk team were able to use File ports to simulate 1 way communications and WCF ports to simulate 2 way communication patterns. This means that in the development tests the team could use BizUnit to effecticely test the solution with these bindings and focus on the logic in their orchestrations and other components.

The one big risk with this approach is that you are not actually testing connectivity to the LOB application and some of the vendor specific situations may result in problems being faced later in testing. There isn’t much you can do about this but you have certainly ensured you are doing an effective job at testing your own code.

I think this model would also be suitable for off-shoring situations where your off shore resource may not have access to the LOB applications to help with testing.

In summary this approach basically uses a different type of port in the bindings for different test environments.

Using BizMock

I came across BizMock a few weeks ago and it seems like a really interesting community project that could be a valuable resource for those who develop BizTalk solutions. I asked one of my team to have a look at BizMock and to try to replicate some of our existing BizUnit tests with BizMock to see what it could offer us.

Unfortunately we were getting the same error that has already been logged on the BizMock issue tracker so we haven’t been able to complete a full comparison yet. BizMock is a very new Codeplex project in its alpha release so being we can live with this, but the ideas that the project offers are very interesting.

The below blog article provides a good overview of what BizMock will offer.

http://blogs.msdn.com/pierreml/archive/2009/02/13/bizmock.aspx

My opinion on BizMock is that I would use it in situations where I have a lot of complex logic in an orchestration which I need to test and external dependencies make this difficult. BizMock looks to be aimed at testing orchestrations rather than an end to end process so it has a clear differentiator to BizUnit. BizMock also offers schema and map testing capabilities but with the enhancements in BizTalk 2009 I’m not sure what value they would offer.

Once there is a more stable release of BizMock I would use it to compliment the tests I currently do in BizUnit. I think managing another set of bindings to configure the BizMock ports is something which I don’t particularly want to do so the trade off of BizMock vs Stubs is just work saved in 1 area to be spent in another. I think the real benefit of BizMock is in being able to concentrate on those test scenarios which are difficult to perform or require lots of manipulation of a stub.

I think in the feature list in the above lined article it discusses the benefits of the tests being written in code vs in xml. Remember in the most recent version of BizUnit you can also write tests in C#, but to be honest I think I actually prefer them in XML where they are much clearer and easier to follow and have a more structured approach and you don’t have to worry about some developer who is no longer around who had a coding style that no one can follow.

I’m looking forward to a resolution to the problem logged on Codeplex so we can look into BizMock in more detail after which I will update this section.

More info is available on: http://www.codeplex.com/bizmock

Summary

Hopefully in this article you got a good feeling for some of the approaches that are available to help you with some of the common yet challenging aspects of BizTalk testing. The things I’ve discussed here are primarily focused around the development cycle where you are trying to perform automated testing as part of a continuous integration approach.

In general my comments were that Stubs are a good way to help you test your solution and deal with the parts of your project that have dependencies to external systems. When you have very tight coupling to an external system you are helped by BizTalk in that you can use a different type of port to reduce this coupling to do some testing with a trade off that you take on some risk of adapter specific implications.

I think Mocking Bird and BizMocks offer some interesting new ideas on how to look at these problems.

One thing that I haven’t mentioned is that in addition to this focused development testing it is also very important to get your real systems together on a regular basis and perform some integration testing. Ideally this would be automated but it can be effective even if its just getting a couple of developers from the different teams together on a regular basis. You will always get some problems this is why integration is usually such a pain but with these approaches we are making our best effort to catch problems early and mitigate as much risk as possible.