The Concept of Object Persistance and Object identity have been around for as long as I've been programming (14 years) and probably longer. Unfortunately most systems and most developers in the Microsoft world have been developed using a database centric approach. The flow to Domain Driven Designs has thankfully finally started to flow strong and hard and I find myself spending less time having to argue the merits of DDD with other developers.

However when Consulting I am regularly faced with Database Designs that use AutoIncrementing Fields or mutable properties or even worse composite mutable properties as the Primary Key in the Database.

Example of AutoIncrementing Primary Key. Person has a PersonID : int as the Primary Key and the PersonID is set by the Database when the Person is first inserted into the DB.

Example of a Composite mutable property as a Primary Key. Person has FirstName: string and Surname : string as the Primary Key in the Database. If these are mutable then some sort of Cascade Update is set so as to ensure that all other related tables FK's are maintained as valid.

Now 12 years ago I used to see a lot more of this type of Database Design I still see quite a lot of this today. The reasons are numerous and sometimes inescapable e.g. I am developing with a legacy database, I have an .xxx.. DBA who is stuck in the 1960's. The company has programming standards that were written in the 80's etc.

In this blog I will discuss why I prefer and rcommend using Guids whenever possible or an application generated Integer (when the DBA has an unjustified fear of GUID's) and also how

When Doing TDD you are trying to Isolate your SUT (System Under Test). To do this you typically create Test Doubles (see previous blog) either automatically with a tool such as RhinoMocks or manually (i.e. you hand code the TestDouble).

When testing complex logic typically in the Logic/Services Layer you land up a significant number of your test doubles being simple Stubs (i.e. they are there to fulfill a parameter list or are being used inside the method but are of no interest to this particular test).

In these cases I typically use RhinoMocks (the new RhinoMocks is awesome) to create my Stubs. The problem is that I then have to register my Proxy Stubs with the IOC Container so that the Resolve works. This is just another overhead with testing. I am a firm believer in making testing as frictionless as possible.

Enter the AutoMockingUnityContainer

I am not going to delve too deeply into the arguments on whether the User Interface should be tested or not. The principles of Unit Testing of User Interfaces are hotly debated in various Blogs. In this particular project I was using a third party control that was returning me a result of and I really needed to test my interaction with this control. The problem was the Control had to be run in STA and most Test Runners run in MTA. This seemed fairly simple since there is a [RequireSTA] in NUnit. Unforturtunately this did worked with some Test Runners but others seemed to ignore this attribute. The solution therefore became to create a Cross Thread Runner.

ComboBox Linker

Ok so I have to admit that I have had to solve this problem several times over the past 12 years of programming. The problem is fairly generic and up untill now there was no general solution to it in Habanero.Faces.

The problem is when you have two combo boxes that are linked i.e. the data from the first combo box filters the data in the second combo box. e.g. Select a Country and you get a filtered list of States for that country.

Learning to write good tests can be hard. There are a lot of things to learn technologies to master and if you have been programming for some time then there are some bad habits to undo.

I train a lot of people to do TDD and have learnt from this that there a few small tricks that will significantly help you write a good test.

This blog assumes that you are familiar with the Red, Green Refactor process of test driven development and have some exposure to a unit testing framework such as NUnit.

I also assume you are familiar with the concept that TDD is not a testing activity but is in fact a design and development activity.

In this blog I go through the parts of what I consider to be a good test.

Changing the Return Value of a Stub in RhinoMocks.