-
Published on 02 Jul 2006 from
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.
-
Published on 02 Jul 2006 from
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.
-
Published on 02 Jul 2006 from
That crazy Scotsman of Podcasting is at it again, or at least at some mad scheme again. With the move from a house to an apartment - and the subsequent need to compensate for a severe reduction in storage space - Ewan Spence is on the (almost) giveaway.
All you need to do is Paypal him [...]
-
Published on 02 Jul 2006 from
In case you had missed it, SQLServerCentral have arranged a deal with Quest to get Litespeed for free.
You can read the review of litespeed here, which highlights the benefits of the compression that litespeed gives.
Because it has to write less dats it is generally quicker to backup, which is always a good thing.
I've had litespeed in my production and test environments for years but never in development. This will be great.
Cross posted from http://sqlblogcasts.com/blogs
-
Published on 02 Jul 2006 from
In case you had missed it, SQLServerCentral have arranged a deal with Quest to get Litespeed for free.
You can read the review of litespeed here, which highlights the benefits of the compression that litespeed gives.
Because it has to write less dats it is generally quicker to backup, which is always a good thing.
I've had litespeed in my production and test environments for years but never in development. This will be great.
Cross posted from http://sqlblogcasts.com/blogs
-
Published on 02 Jul 2006 from
Poor weather conditions prevent the Discovery space orbiter from launching for the second day running.
-
Published on 02 Jul 2006 from
Today, 2nd July is my birthday! I am glad they moved Tech Ed Europe to November this year, as I am sick of spending my birthday at a conference!
Oh and, yes, I am just 20 years old... if I count in hex that is ;-)
-
Published on 02 Jul 2006 from
The Diary of a Long Voyage - learning VS 2005 and SQL Server 2005 from scratch
2nd July
This week has been given over mostly to being a father. My daughter has just taken
a job in north London - she is a teacher - which requires her to move away from the
family home. So I have been the chauffeur/advisor in getting her set up. This is the
first time I have really got a close look at the housing market for over 20 years.
As a teacher - with 2 degrees - she is totally unable to buy any property without
over extending her finances. To buy even the cheapest flat/terrace she would have
to borrow, as a first time buyer, some 7 times her salary and have absolutely no budget
for anything else. In north London the rental market is fairly good - there is, if
anything, an over supply of rental properties where everyone went out and bought a
property to rent so they could capitalise on the ever increasing prices. However I
believe that should the interest rates increase significantly then the housing market
will destabilise. Rents would not cover mortgage payments, salaries would not cover
mortgage payments etc. I still remember the '70s when rates went up to nearly 15%
and the chaos that caused.
This week I have been reading about Web Services - I have many books on the subject
- see here.
On reading these books I have observed one thing in common - the authors get sucked
into describing the internals of web services - what I was looking for was the 'dummy's
guide to writing a web service'. A parallel example- if you want to find out how to
use a telephone it is not necessary to know how the exchange works. As a result I
will attempt to produce a simple guide myself and publish it on my website. Web services
are really rather simple in .NET and are nothing to be frightened of.
So let me start here with some simple facts as I see them:
-
A web service is a misnomer. I would say that a web service is in fact 'an interface
can work over a network'. A web service is a way of 'black boxing' some functionality
and presenting the interface to others - rather like a 'global' object.
-
A web service is VERY flexible in what if can do - the limit is only the developer's
imagination.
-
A web service can be a business object - for example a credit card number verification
service that you might provide the card number, expiry date and security number. The
web service then executes the business rule to determine whether it is valid and returns
TRUE or FALSE
-
A web service can be a data access object - for example returns a typed dataset of
the adventure works table 'product'. This way data could be made available without
knowing about the server/database. For example moving from Oracle to MS SQL Server
would require no application changes.
Because of the network interface capability of the web service then in an organisation
the 'credit card verification' function could be written once and made available over
the intranet to all that need this function. Should a change be required in the logic
that determines the validity then only the web service would be changed - all the
applications that use the web service would continue without change - and when the
web service changed then the validation for the whole organisation would change at
the same time!
Sounds like the golden pill? Well maybe - except that there is a performance hit each
time it is called. However the hit in practice would only be significant on high volume
applications.
I heard from the Enterprise Library team that the Web Services Block is progressing
and that there is a new pre-release version is available.
I also received a new book "Effective Use of Microsoft Enterprise Library: Building
Blocks for Creating Enterprise Applications and Services" published by Addison-Wesley.
This is newly published. Publishers reference here