Contributing to BizUnit/BizUnitExtensions

May 31, 2007 at 9:17 AM

I've started looking into using BizUnit/BizUnitExtensions for testing a BizTalk solution I'm working on. The concept and framework are excellent although I'm having some difficulties applying it to my specific scenarios, although I don't think my scenarios are that specific and think they could hopefully add value to alot of people. I was wondering then if I was to develop some custom steps/validators how I could get these added to the core solution if you think they are generic enough and have wide enough application. I'm sure alot of people write their own custom steps but would obviously much prefer not having custom builds etc for obvious reasons such as incorporating future BizUnit upgrades etc.

What I'm specifically trying to test are BizTalk WSE adapter published web services. I tried using the SOAPHTTPRequestResponseStep but hit a major problem in that the WSE Adapter published web services include the input/output messages as xsd file import declarations in the WSDL. BizUnit does not currently import these and therefore the codegen stage crashes as it doesn't have all of the element definitions in the WSDL. I have a fix for this which I've posted to I haven't actually got a scenario working with SOAPHTTPRequestResponseStep so some of what I'm about to say is based on assumptions so forgive me if I'm incorrect here. I'm assuming due to the proxy class generation, any message I want to send using the SOAPHTTPRequestResponseStep must conform to the web service interface, therefore meaning that I can't test invalid payload scenarios to see that my web service/WSE behaves as expected in these situations. Also I'm assuming that due to having generated a WS client proxy the payload file supplied to the SOAPHTTPRequestResponseStep only contains the soap:Body payload and not the full soap:Envelope. How do I therefore populate/test custom soap:Header values? There is always the risk toto that the client proxy could change the message (e.g. add in any mandatory attributes with default values that I don't want it to). Also due to using a ws client proxy I assume the XmlValidationStep can only be used to validate the payload in the soap:Body response and not the full response soap:Envelope. Please could you let me know which of my assumptions here are correct and which aren't.

So here's what I'm proposing:

1) A BasicSOAPRequestResponseStep. I have this one done already and it is simply a copy of the HttpRequestResponseStep which has the xml extended to take a SOAPAction which is then added to the HTTP headers. The payload file provided is therefore the full soap:Envelope complete with any custom soap:Header values, etc and it doesn't need to conform to the WSDL. The payload provided is exactly what gets transmitted. Very simple, very flexible.
2) A SOAPBodyXmlValidationStep. As the xml being checked when using the BasicSOAPRequestResponseStep is now the full soap:Envelope rather than the contents of the soap:Body then the xpaths required to use the XmlValidationStep may be quite cumbersome as they would have to include the soap:Envelope/soap:Body etc. Also the schema to validate against would no longer work with the XmlValidationStep as the schema will only validate the soap:Body contents and not the full soap Envelope received. Therefore the SOAPBodyXmlValidationStep could be used for validating the contents of the soap:Body in a full soap:Envelope by extracting the payload and then working just like the existing XmlValidationStep.
3) To complement the SOAPBodyXmlValidationStep a SOAPHeaderXmlValidationStep could be added although the existing XmlValidationStep could be used for this. Hopefully what the SOAPHeaderXmlValidationStep will do is obvious.
4) It would be great if dedicated less technical test resources could set up the test scenarios but I feel that the fact we need to use xpaths in the format similar to "/local-name()='PurchaseOrder' and namespace-uri()='http://SendMail.PurchaseOrder'/local-name()='PONumber' and namespace-uri()=''" is a hinderance to this. If we could use something like /po:PurchaseOrder/PONumber then this would be much better. This however needs a XmlNamespaceManager to be added to the SelectSingleNode call. Therefore what I've done is added the following helper function to the XmlValidationStep which navigates the document being checked and sets a XmlNamespaceManager with all of the namespaces in the document which is then passed to the SelectSingleNode.

private void AddNamespaces(XmlNode currentNode, XmlNamespaceManager namespaceManager)
// Add the namespaces from this element
if(currentNode is XmlElement && ((XmlElement)currentNode).HasAttributes)
foreach (XmlAttribute attribute in currentNode.Attributes)
if (attribute.Prefix == "xmlns")
namespaceManager.AddNamespace(attribute.LocalName, attribute.Value);

// Add the namespaces from this elements child element
foreach (XmlNode childNode in currentNode)
if(childNode is XmlElement)
AddNamespaces(childNode, namespaceManager);

So what do you think to these. Good idea/bad idea.? Are they already in the product and I just haven't found them? Do you think they are generic enough to get added to the core product?


Jun 3, 2007 at 8:17 PM
Edited Jun 3, 2007 at 8:19 PM
Hi John,
I too have found the SoapHttpRequestResponseStep rather limiting and the only way i could get it to work with ordinary webservices was to do a manual preparation step in NUnit where i instantiated the proxy and filled it up and then serialized it to xml to give me the format of the file that it would allow me to send using that step. I also got stuck at the testing of invalid messages area, since the messages could not go to the webservice (unless there was only something wrong internally -(ie) some business rule validation etc). Now a colleague of mine has made some fixes recently to the 2004 version which allows you to send the messages as shown in the standard ASMX helper page, but i havent had a chance to check how that works.

Your suggestions sound good, BUT if you want to add something to the core, you would have to ask Kevin to do that or send him the code and if he thinks it can be added to the core, he may be willing to.

I am going to stop releasing the core with extensions now as the core is now being upgraded by Kevin and we want to avoid any confusion in the community. In fact i would suggest you take a look at his 2.3 beta to see if the SOAP step is any better now. I havent had any time to play with that since he put that up.

in terms of the extensions library, If you have tested your steps and they work fine, then i am quite happy to include them in the code base.There will be a cleaned up release of extensions shortly (to remove the core) and i can add them there , or i can just put some pages here where i can attach your files and people can download the individual steps if they dont want to take the whole package. Even better, if you would like to do that, i can always add you as a contributor to the project and you can have the freedom to post your steps!!! we are always happy to see more contributions.

Let me know what works best..

Jun 4, 2007 at 4:04 PM
Hi Benjy,

Thanks for the reply. I had already tried the 2.3 beta but the SOAP step problems still exists. Thanks for the advice on contacting Kevin and the offer of including my new steps (the one that solves my SOAP step issue came from a colleague who had the same problem and had already solved it so he deserves the credit). I'll try posting to the bizunit wiki to give Kevin first refusal on the new step and so based on his response I may be back.


Jun 4, 2007 at 7:55 PM
Ok, no probs...

Oct 30, 2007 at 8:01 PM

I'm thinking of writing TestSteps to send/receive messages to/from SharePoint services using the BizTalk SharePoint Adapter Web Service and contributing it to this project. I was wondering if there's something similar already or perhaps it's just not a good idea.

Please let me know what you think of this.

Oct 30, 2007 at 10:00 PM
Hi Frank,
That would be great. Any set of steps to enhance the reach of BizUnit would definitely be welcome...
To get the steps here you can send them to me or i can add you as contributor if you wish...

Btw, Have any of the extensions here been of use? just curious to know how you are using BizUnit ...

I will be uploading the latest set of extensions *(tested against the latest BizUnit core release) later this week

Oct 31, 2007 at 9:04 AM
Thanks, I'll let you know of my progress.

I have very little experience with BizUnit and even less with the Extensions: I'll let you know of any feedback I have. In any case my opinion is that any serious BizTalk project should use this stuff so I'm sure I'll gain experience with it.

I'm currently looking into putting this into our nightly build and software production line so any links or other feedback is appreciated.
Oct 31, 2007 at 11:49 AM
Thats fine.. all comments and feedback are appreciated. I know that the extensions arent actually explained beyond the hints in the NDoc file so i need to get cracking on that, otherwise people wont be able to use this properly (other than the obvious entlib steps) and be able to choose (ext vs core) when there are similar steps in the core.

We have an automated build but it isnt scheduled to run nightly or on CI trigger yet. Since we drive BizUnit through NUnit , we had a NAnt task (now being ported to MSBuild) to call NUnit on the test project.

We also use Console Applications for the unit testing so that we can use app.config files even when within the IDE. (I gather that the NUnit GUI/commandline allows a DLL to have a config file but we have never got this to work consistently so we always use console apps)

Since the auto build is currently kicked off by hand, we havent got round to setting alerts if the BizUnit tests fail. Thats next on my agenda.

Nov 30, 2007 at 10:35 AM
Hi Benjy/John,
I know I'm a few months late to this discussion...

John, you mentioned in your first post about the pain of writing full XPath queries statements in test cases for non-technical people, and suggested the use of queries using prefixes instead.
In my experience, then can be just as confusing - I just had a frustrating conversation with a tester about what a prefix was!
Still, the idea of auto-generating a name-space manager is a good one - it would be useful to see this as optional add into an XmlValidation step (i.e. being able to turn it on from the test case).

In case it helps, I wrote a utility which will automatically generate a Test Case for use with the XmlValidation[Ex]Step – it automatically generates the full XPath statements for every element/attribute from an Xml instance (along with XPath statements for counts of repeating elements) – you can just right-click on an xml file and it will generate a test case from that file.
More information here:

I also have some suggestions on a new XmlValidation step – but will create a new thread for that.

Daniel Probert
Dec 4, 2007 at 6:16 AM
Hi Daniel,
This looks like an excellent tool. I'll take a look at it asap. Im currently on hols actually. I plan to start on some test case generation stuff as soon as i get back in the New Year and i was planning to start with something similar - to generate sample xml files and test cases for a given XSD. Maybe we could link the tools up.