First of all let me state that I admire the effort Kevin Smith has put in to BizUnit 2.0 and 2.1 and I dont really want to grumble but frankly I’m getting quite frustrated with BizUnit now. [Btw, Im not just going to whinge about it … I’ve put in an application to join the workspace and intend to at least fix the typos and put some documentation in].
A question of ‘Context’ : It started off quite well and its really simple to write the basic tests like checking for files, validating their contents and even manipulating database contents. But now that we have got a battery of 25 or so tests, maintenance has become a nightmare. For instance, in one of our tests we have about 5 or 6 different steps that all work on a particular folder and some files in them. The tricky bit is that the file path and name are duplicated in 5 places and one change requires a huge amount of work to go and change all those occurrences.
I was thinking that a concept like NAnt properties would have been so useful here. We could define all these common variables in one place and use them across the scripts. I get the feeling that the BizUnit Context class might prove to be handy to do this kind of thing, but the documentation is so poor, i cant find any info how to use it. Worse, the GDN community appears to have gone to sleep in that particular message board. I’ve experimented for days on end, but no joy. The author posted a rather cryptic one line example (to an earlier query) saying that we could do “context.Add(key, object)”, but neglected to say where you would define and instantiate the context object. When i tried to use it, the system always complained of using an unassigned context variable. Moreover, defining it in code is not of much use because in BizUnit the meat of the system is the Xml test case so we need to have an ability to assign those variables in Xml. The doc for the Context Manipulator step seems close to what we need, but again, agonisingly, the example is not complete enough to make sense. There isnt any example to say how we can pick something from an existing context in one of the test case xml steps and use it (like the way we would use ${property} in Nant). What makes it even more confusing is that the source code shows context being passed between various steps but in BizUnit you dont invoke individual test steps in the CS file. You simply point the BizUnit constructor to the XML file and then say RunTest. Thats it.
Then there is the Text Context Loader with an absolute gem (sic!) of a comment. Heres what it says in the remarks on how to use it . “Here’s the SearchString, but then skip this bit and return: TargetFindString” Huh? Say that again?!! I’ve gone over that several times but it doesnt make any sense. The same comment is carried over to the 2006 version including a really problematic typo that I’ll explain below.
The “Parameter” typo: This little beauty wasted 3 hours of our time one day. BizUnit provides a sort of extension mechanism called a DotNetObjectInvoker which allows you to call any of your components to do stuff you want provided it can accept inputs and return an output. Now when you use this you define a set of parameter elements in Xml and BizUnit picks that up, reflects over your type and executes the method. The funny thing is, the Xml element is spelled “paramter” in the xml sample and the code. So, one of our developers had not noticed this and had used “<Parameter>” in his Xml file. Of course, it wouldnt work. It kept throwing “Object reference not set to instance of an object” all the time. We couldnt figure it out for a long time because we had unit tests for that component and they worked fine. Finally i spotted the reverse typo. !! What makes me rather puzzled is why this has not been corrected in v2006. Kevin claims that there have been over 2000 downloads of this tool so far, surely someone should have come across this error? There are quite a few other typos too (such as the SoapHttpRequestResponse step) and there are quite a few bugs still open on the message board.
As i posted sometime earlier, we have Xml schemas which make extensive use of includes and imports. This cannot be validated by the inbuilt XmlValidator in the BizUnit system so we had to use the DotNetObject invoker over the free AltovaXml library to do what we needed to do.
Another limitation is that there seems no obvious way to test untyped webservices. I accept that this is not usually the norm (I have come across systems with the single catch-all ProcessMessage(string input) signature and hot debates rage on whether this is good practice or not, but i wont go into that here now) but we do have some internal webservices (orchs published as webservices) which take XmlDocuments as input. The SOAPHttpRequestResponse step isnt of much use here .This step requires you to define what the type name of the input message is and the WSDL doesnt show anything useful (since its only an XmlNode). So, to work around this we needed a combination of BizUnit and standard NUnit /.NET. We defined the constructor explicitly to use the TestGroupPhase.TestSetup enumeration and pointed that to an Xml file purely meant for the folder/db cleanup etc. Then in the test we loaded an xml doc from disk, put that into an XmlNode and called the webservice using its proxy. After that we pointed bizunit at the xml file and let it run the rest of the steps. This isnt an elegant solution because it disconnects the xml from the rest of the test (in the source code) and makes it difficult to read, but for now this will have to do.
I do have some options up my sleeve though. Either I write another custom step which can call untyped webservices, or use reflection and pass a reference to the proxy object into my custom class or thirdly, look at DynWSLib which is a .NET library to dynamically call webservices at run time without needing proxies, written by the gurus at thinktecture. In the spirit of not reinventing the wheel, im going to look at option 3 first and see if i can incorporate that, failing which i will do option 2 and then option 1.
Extending BizUnit and the possibility of a GUI: I was reading up the blogs at Conchango and it looks like the folks there have been extending Bizunit quite a bit but it looks like theres a lot of IPR involved so probably no hope of that being released for general consumption. I also read somewhere that in one company they defined the test cases in Xml (so business folk and testers could define test cases) and then generated the xml for the test cases from there. This sounds like a good idea. However, IMO, what would be most useful is a nice GUI which allows you to define test cases and reads prewritten test cases and allows them to be edited. This could look like the Ent Lib configuration wizard. If i can squeeze some time out now, i may just dive into this GUI option and see what i can come up with.