Unit Testing SharePoint in a 64-bit Environment
I’ve recently upgraded all my development environments to pure 64-bit (except, of course, for Visual Studio, which continues to be a 32-bit laggard) to take advantage of the extra memory space available in x64. When working with really large lists and datasets, having less than 1GB for the w3wp process is self-defeating – it’s not uncommon to crash the worker process even with paged gridviews. Plus, the performance of SharePoint and SQL Server on 64-bit is head and shoulders above x86, making it easier to work with multiple VM’s at once.
That being said, I’ve been behind the curve in getting all the code in my core presentations converted over to a true MVP pattern with unit tests and the like, so I decided to take some time ahead of the Devlink conference later this month to refactor my high performance code samples. What should have been a relatively simple task soon turned into a man-against-machine bare-knuckles cage match. I really like the MSTest framework in Visual Studio, so I started rewriting all my old NUnit tests to take advantage of the nice IDE integration that Visual Studio Team Test 2008 offers. Within a few minutes I ran head first into an unmovable wall. No matter what I tried, as soon as I tried to run a test against any methods which referenced the SharePoint DLL’s I got a "System.IO.FileNotFoundException" error. No matter what I tried, VS simply would not run my tests.
After hours and hours of digging through Process Explorer, chasing down output in the debugger, and generally giving myself a splitting headache, I finally stumbled upon Lars Fastrup’s post on issues with vstesthost.exe in a 64-bit environment (Lars, I owe you a drink in November). Seems that the VS team never imagined we’d be running test cases against 64-bit DLL’s – here we are in 2009 and vstesthost.exe is still a 32-bit process. Great. So now what?
Well, it seems that there is no way to get VS 2008 to run tests in a 64-bit dev environment so I had to drop back to NUnit. Now, to be fair, NUnit and TestDriven.net are fine frameworks but they lack true IDE integration. I want a GUI inside of VS just like MSTest – I don’t want to launch a clunky WinForm app just to view the results of my tests. Plus, NUnit is just s-l-o-w compared to the Visual Studio test framework. Just what I needed – another slow add-in to put an anchor on my testing process.
So if you see me running NUnit for my test fixtures now you know why. We can only hope that the VS folks have seen the light and the VS2010 test framework will be native 64-bit. Anyone want to make a wager on the chances of that happening?
I’ve been using Resharper’s Unit Testing Integration for NUnit, MBUnit and even MSTest for some time now. Alternately, you could try the Gallio project with is a universal xUnit test runner framework.
I am currently writing my unit tests (all NUnit) against SharePoint on an x64 vm. So far it has been difficult to adequately isolate tests to small units – is there some hidden approach that will make it easier (I haven’t tried TypeMock yet)
Quick tip: right-click on the test you want to run and there will be a TestDriven.NET context menu, which allows you to run tests, run tests w/ debugger, etc. Test results appear in the Output window. I believe failed tests also appear in the Errors window along with compilation errors, but I never use this feature.
If desired, you can also map a hotkey (everything’s under TestDriven.NET.Something) to run the tests at any time. I like mapping ReRun Test to a key, so that no matter where I am in the codebase, I can hit the key and it will build+run the test I’m interested in.
I don’t think TestDriven.NET works with MSTest anymore, so you may have to go back to NUnit to use it.
Also, big TD.NET gotcha: if you have GAC’ed your assemblies, TD.NET will look for assemblies in the GAC first, THEN your local project copy. So make sure you’ve un-GAC’ed everything, or have GAC’ed your most recent copy, before running tests.
I had a long, ugly troubleshooting session before I figured that out.
Guys, Great article and very very interesting blog. That’s one thing I’m really looking forward. Looking forward to reading more from you next week.