I know its been rather quiet on the BizUnitExtensions front, but never fear, theres lots of stuff to come. But firstly, i do hope Kevin Smith responds to my comments on his workspace on joining forces. Im still waiting patiently. Although its good to see a new BizUnit core release with bug fixes and changes, its actually beginning to get problematic now because we have made changes to the core of the BizUnit class and other classes such as Context and now we have to port everything to the latest BizUnit codebase in order to keep things consistent and doing this to a code base which has now structurally changed is not easy. Added to that is the fact that we also wanted to change the structure of the code base (so we keep the standard test steps in one, biztalk specific things in another, msmq in yet another etc) so thats got to match up as well. I suppose these are the kind of scenarios where the C# 3.0 extension methods would come in really handy. Maybe its a good time now to break away from the BizUnit label and move to the more generic integration testing framework. What do BizUnit (and Extensions) users think about this?
Anyway, a good discussion has started on the forums at the extensions site (www.codeplex.com/bizunitextensions) with one of the new users querying BizUnits actual value (Why BizUnit) and finding some answers in the roadmap. I guess the reply to the question would be worth a blog post on its own!
So whats cooking with the Extensions project? Well, first of all 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). (Speaking of MbUnit, it definitely looks much better than NUnit and i should try running BizUnit inside MbUnit to see what extra stuff i can squeeze with MbUnit.)
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. If you are using the tool currently or planning to then head down to the codeplex site and post your thoughts on this or email me.