I like 64-bit SharePoint and have more or less forgotten about the 32-bit editions by now. Consequently, my development environment is also 64-bit all the way. Now, I am also a great fan of unit tests and find them very convenient when developing software for SharePoint. Besides the fact of having reproducible tests they are simply also a great instrument as you write code. It is simply great to run and test your central pieces of SharePoint code directly from Visual Studio before exposing them in a Web Part, Workflow or the like. I have been quite happy with the integrated unit testing facilities in Visual Studio until the day I switched my dev environment to 64-bit.
Then it suddenly stopped working. Most of my existing unit tests consistently failed with strange errors I had never seen before. In the old 32-bit environment the tests still ran like a dream. I then started researching some of the errors and it turned out that only unit tests resulting in calls to the SharePoint Object Model failed. For instance SPFarm.Local returned null and the next line of code then failed with a NullReferenceException! Yes, this is what I mean by strange errors - I never expected SPFarm.Local to return null when the farm is up and running just fine.
Well, to cut a long story short I finally figured out what was going on. The problem is simply Visual Studio that always runs the unit tests inside a 32-bit process named VSTESTHOST.EXE. This is fine as long as you are using a 32-bit edition of SharePoint but it is not fine for the 64-bit editions. The 32-bit VSTESTEST.EXE process cannot load the SharePoint assemblies that are compiled for the 64-bit platform. The problem was difficult to track down as the process did manage to load some assemblies like Microsoft.SharePoint.dll and did therefore not have any trouble locating the SPFarm class. I think the problem occurred deeper down under the hood when the SharePoint classes internally accessed other 64-bit only assemblies or 64-bit DCOM objects.
The solution? Use NUnit and forget about Visual Studio. I have tested with Visual Studio 2005 and 2008 and the story is unfortunately the same for both. I am not sure why Microsoft did not consider this scenario but I have a plea to the Visual Studio team: Please consider a fix for this problem in the next service pack.