Extensions and Core

Apr 25, 2007 at 8:09 PM
Edited Apr 25, 2007 at 8:10 PM
Hi Kevin, As indicated in the main page, i think its more easy to read comments and discussions here. My responses are as follows

(1) As soon as you put the beta release, we'll have a look at which bugs were fixed and which remain. One thing i did was to revise nearly all XML comments cos some were actually copy paste errors and sometimes for a step, the wrong code sample was placed in. I also revised the DotNetObject invoker to correct the "paramter" typo and allowed it to use the context (and released that under DotNetObjectInvokerEx). Dont know if you have seen it , but i have also written up a tutorial on the Context object.

(2) yes, please let me know which changes you are rejecting. I would like to discuss them esp if my extensions wont work as a result!!

(2b) some of the Ex steps are just simple derivatives of your own with the addition of context properties and some strong typing (in the case of orchestration conductorEx which uses explorer.OM instead of the WMI dynamic route). Perhaps we can integrate them

(3) I thought it would be useful to have all properties publicly settable. That way in a GUI, say with a tree view , when a user chooses a step, we can use reflection to dynamically pull up all the members and allow them to be set directly (a bit like enterprise library config editor). But both the core and the extensions need to be consistent otherwise we cant do this. (We could always have an intermediate step where we pick up all properties from some context file and then write the test case when the user is finished, but why not just use reflection?
Setting props publicly could also help the folk who are more used to NUnit and MbUnits way of working and wont harm BizUnit but could open it up. Perhaps i should put up a poll or voting mechanism for this.

(4) Re: GUI tools, thats a pet topic of mine. I appreciate the points about competitive advantage, Personally i prefer to give back to the community so i would like to make the add-ins, DSLs etc that we develop available to everyone.

(5) entlib: again, appreciate that you cant see the value here but some folk have asked for it. Again, the core would need to allow this to happen otherwise extensions cant do anything. (until C# 3.5 comes along and we can use some extension methods) .But if you do put in some IoC mechanism (constructor injection of logger for instance), then we might be able to make this work.

i'll send you some dummy code which i think would be a useful way to use the API (with the constructor injection of logger, test case provider injection etc) let me know if that would make sense.

(6) Re: ITF. I guess "ITF" itself doesnt add any value,just maybe some "feelgood" factor for those testing non biztalk projects. I would prefer to keep working with BizUnit now rather than fragment the community with yet another tool (your license does allow derivatives and modifications!! :-))

Glad to see you like the idea of WCF and WF steps.. I'll keep working on that.

couple of other things
(a) it looks like it is possible to create a proper XSD. It just occurred to me that although all elements are named with TestStep, the code doesnt look for nodes with this name, so if we were to explicitly name them FileCopyStep etc the code would continue to work.. gotta test this and see.
(b) i've often run into some difficulties with the fact that that the leaf namespace and main class name (bizunit) are the same. could we get the main class name changed to something like TestRunner() or would that be too much of a break?


Apr 28, 2007 at 10:42 PM
Hi Benjy,

Afraid I've not got time to respond to all of your comments, in the mean time take a look at the 2.3 release which I posted a week or so back.