August 2004 - Posts
Found an interesting post on these blogs by Brian Button. Wonder what the other folk here think about Programmer Tests being used as documentation and specification tools. I posted a feedback comment to Brian's post on this topic.
As some of you who read my earlier post on Agile Methodologies and Documentation will know, I have some rather strong feelings on the subject. Still, I like learning new things which is why I have taken to TDD like a fish to water and would value any advice on designing tests better and making them more understandable in terms of requirements coverage.
I'm looking forward to Brian's article (hopefully it isnt a subscriber only article at the site he is writing for).
PS: I also looked up Daniel Cazzulino's post about the Component Designer being removed from Whidbey and went over to the MSDN Product Feedback site and posted my two cents worth!! If you have strong feelings about the component designers and the steps MS is taking in that direction generally, you should let them know via this mechanism too.
Data Extraction layer development should be classified with Health hazard warnings. Still keeping my head down (or rather, its been forced down with this millstone) and trying to finish off my current set of components.
As I mentioned in some of my previous entries, one of the requirements I have is to develop this component that extracts data from a legacy DB into XML Messages. Actually , the DB is not that old. In fact the application is only a couple of years old and implemented with SQL Server as data store. The key problems though are (a) the application is completely monolithic and not designed with any extraction requirements or services in mind. (It does what it needs to do, but only when used with its own front end) and (b) from a DB design point of view, suffice to say that it does not pass muster.
Since the XSD's that govern the messages are so FAR FAR APART from the DB Design, writing SQLXML will not work. (At least, with my limited knowledge of SQL XML it wont work and I dont have the time to put in a 'spike' as the XP folk call it to investigate). I looked briefly at typed datasets but threw them away. Too much code to write.
So what did I settle for then?
- I created a set of classes for the XSD using the XSD.exe. I kept this in a separate TYPES dll.
- I created a set of SQL DB views corresponding to the major elements in the XSD. This encapsulated all the mappings to various tables, string manipulations, data format conversions, joins etc.
- In the main application I instantiated classes from the types DLL (collections wherever necessary) and then wrote the SQL Code to get the data from the views and fill up the class members.
- I wrote a little utility that generated the 'standard' code which instantiated the data reader and assigned values to the members from the data reader. This saved me a lot of time.
- Once i got the main objects, I tied them up to the root class and then used the default serialisation (XmlSerialiser) to generate the Xml file.
This works fine. In fact I'm thinking of more code generation options using the basic approach listed above.
Maybe the points above will help someone else. I'll explain why the typed datasets approach is no good for my requirements in a later post.
Have fun.
I got an immediate response from Jamie Cansdale about the NUnit Add-In issues I mentioned in my last post. Here's a brief summary of his points and my follow-up in case you are interested
(1) Project Item Templates : Jamie will be working on getting the project item templates to work correctly. This is great. It is quite a time-saver. I looked at Enterprise Templates briefly to see if i could quickly code one up but discovered its not for the faint of heart. Need to spend more time understanding it first. But then again, its supposed to be much much easier in Whidbey with Project Templates and Project Item Templates (I read this in a post somewhere on MSDN - can't remember where) so maybe it would be better to just wait a little while more.
UPDATE: I found the post. Jeremy Bostron has also clarified (in response to my question) that it is not intended to replace Enterprise Templates.
(2) Debugging Issues: What was I actually trying to do with the console app stuff and all that ? Basically, I have all my tests in a separate project in the same solution. The namespace is just <application-namespace>.Tests. Now because of all the problems I have had with trying to setup config files for DLLs, I have set the project output to be a console application. In each of the tests I am trying to do a Test with..debugger and no matter how many breakpoints I set in the test class methods, it jumps past all of them and goes straight into the main class I am testing. I tried re-setting the output to be a DLL and lo and behold, the step through within the test class worked fine.
(3)Config Files for DLLs: Jamie suggested I use the method where I create a config file for the DLL and name it "[application].dll.config". This should then be placed in the bin directory along with the DLL. I have read about this approach in lots of places in the past and tried this lots of times and it didnt work at all. Thats why I gave up and placed all the configuration data for the main DLL in the registry and put the EMAB stuff in the app.config for the Test executable.
Anyway, I'm able to make progress for the present. Took a look at Scott Mitchell's EMAB Custom DB Publisher and used the idea to roll my own DB publisher. That worked fine.
I also saw some other interesting looking applications on the sourceforge page for NUnit including one called VSNunit and one for pretty test reports. Must try them out.
Also came across a cool article on Enterprise Connection String management. Just saw it recently and it lays out a lot of the issues clearly. Its a discussion, not a solution so check it out and contribute if you can.