BizTalk testing, why choose BizUnit

Topics: User Forum
Mar 16, 2007 at 11:30 PM
This is in response to Santosh's blog post http://dotnetjunkies.com/WebLog/netblog/archive/2007/02/11/BizUnitExtensions_Suggestions.aspx.

Some of this might be better geared towards the creator of BizUnit, but this board seems to have more activity.

As a new BizTalk developer starting their first project, the idea of a BizTalk testing framework is an excellent idea. I've downloaded the latest version of BizUnit and finally got it to do something. However, I'm left wondering, what benefits does BizUnit give me writing my tests strictly in nUnit? Trying to write up XML (even with the BizUnit snippets that are available on the web), is still a pain compared to the intellisense world of nUnit and Visual Studio. I almost think it would have been better to recompile the BizUnit project so that I can reference all of the Step classes and their properties. With the exception of having to recompile by nunit tests, what benefits do defining test steps in XML provide?

One question I have that might help me understand the reasoning behind using XML to define the tests is, how can I reuse steps from one test in another? I have to do allot of database inserts, and it would be nice to only have to define this inserts once, as well as to be able to change some of the parameters in these inserts based on the current test I am in. I am fairly confident I could get something up and running using c# and nUnit exclusively in a couple of days, but I'd really like to save whatever time I can and use something that is being actively worked on (at least with BizTalk extensions).

Finally, on another blog post you ask what articles we'd like to see. I can pretty much figure out how BizUnit works by going thru the code, what I'd like to see is a Best Practices when using BizUnit. How to reuse tests, where to store things like connection strings (figured out how to use the context object thanks to your code project article), etc.

I don't know if I will have time to contribute code, but I can definitely contribute ideas, give feedback and test stuff out as I work on my current project(s) using BizTalk.
Coordinator
Mar 21, 2007 at 11:47 AM
Adam,
This is good stuff. You have highlighted valid questions (why Bizunit, what are the best practices etc) . Give me a couple of days to post a detailed response. In the meantime, check out the roadmap. Im hoping that within a few months, this tool will be really compelling . (:-) , well, i can always hope cant I?)

cheers
benjy
Mar 21, 2007 at 5:50 PM
Benjy,

I had some time over the weekend to start writing some tests and was able to begin to address some of the questions I had. I also had a look at the road map, and it seems that alot of my issues have already been thought of. I believe that some of the extensions will be of immediate use.

I really like the idea of a GUI front end for creating the tests. I got to thinking, and not only would this make a really good testing tool, but also a very good server/service monitoring tool. Have a GUI front end to create the tests, then write a simple .Net service application to run the tests in the background and you can continuously monitor BizTalk, database, Pop3, etc.

Hopefully my project(s) for work will allow me the opportunity to contribute something back to this project.
Coordinator
Mar 24, 2007 at 4:36 PM
Adam,
Glad to hear that some of the questions have been answered. As we indicated in the roadmap we believe that BizUnit is rather developer and XML intensive and it needs a fair amount of work to make it really compelling and less error prone.

I need to put down a release calendar showing whats coming up (based on the roadmap) in the next few releases, but right now the target is to get all the step properties, constructors etc public and to get entlib logging working.

I have finished the entlib logging and will make it available as soon as possible. Its rather raw right now (ie) its a simple log format that more or less mirrors the console log but to a text log sink. i hope that this will stimulate some discussion in the community so we can improve the kind of logging (to event logs, perf counters etc).

Making the properties etc completely public is proving to be rather involved and raises lots of questions. For instance, if one could execute a step (for example, filecopy) independently (by just setting the properties and calling Execute) and could do the same for all steps in the test case, then the question arises as to what value does the BizUnit testRunner provide ? some possible answers are that it provides
(A) Execution context (but this could also be set and passed in) and the ability to keep a constant thread of logging through all the steps and
(b) also provides parallel execution (but MbUnit could provide that)

I think it might be a better option to provide the ability to set step properties in code but once we create a collection of steps, we would pass the collection to BizUnit and say RunTest(TestStepCollection). This way BizUnit can manipulate context and keep full control. The Execute() methods would all then become "internal" and available to friend assemblies rather than public.

Let me know if this makes sense.

I like the idea of the service application to run the tests and monitor stuff in the background. i'll add it to the worklist.

cheers
benjy