views:

158

answers:

2

I've set up a 64-bit TFS 2008 build server with Sharepoint, continuous integration and out-of-the-box MSTest. Unit tests for plain business logic classes run just fine and test results are published into TFS. However, any test that uses Sharepoint's API fails horribly, SPFarm.Local returning null and so on. Is there a way to fix this?

The tests run fine in an otherwise identical 32-bit development environment (Windows Server 2008 under Hyper-V, Sharepoint patched up to June 2009 cumulative update) from both Visual Studio and command line, so the problem is not about improper use of SPContext.Current or any other part of the API that needs to be run in a web server context. I've ruled out permissions issues, because the build agent account can deploy the solution and create site collections just fine with stsadm. The next culprit could be that the unit tests were being run with a 32-bit process, which couldn't access the 64-bit Sharepoint API properly. I tried a workaround, but it has the side effect of disabling TFS support in MSTest.

Do I have to wait for 2010 versions of MS tools (and hope for the best) or is there a third-party test framework available that runs natively in 64 bit and can publish test results into TFS 2008?

+2  A: 

This is occurring because SharePoint has no context in the tests that are being executed. SharePoint's context (particularly thinking of the SPContext.Current object here) is only populated when it is run inside an ASP.NET page as part of an HTTP request. MSTest isn't doing this.

If you need to perform integration tests (distinct from unit tests) against the SharePoint API, you could use Typemock Isolator for SharePoint. This will mock these SharePoint objects so they are no longer null. See Francis Cheung's blog for an example.

Edit after comment: I don't have direct experience with this but can't think of any reason there would be a problem between 32-bit and 64-bit. Please look closely at any differences in environment and configuration.

Alex Angas
+1 for the Typemock Isolator for SharePoint reference. Started looking into that tool myslef recently.
Colin
The tests are not using SPContext.Current, nor are they using any parts of the API that use SPContext internally (like in my earlier question about PortalSiteMapProvider). The tests run just fine in an otherwise identical 32-bit environment.
Hirvox
@Hirvox: Right, you didn't mention that in your question. It could be a 64 vs 32-bit thing but my guess is a difference in environment/config.
Alex Angas
The question has been amended with additional information about the environment.
Hirvox
A: 

I've just run into this issue myself as well. After hunting around on the net, I finally found this article: http://fastrup.net/post/Visual-Studio-Unit-Tests-and-64-bit-SharePoint-does-not-play.aspx

I was already leaning in the direction of NUnit to see if it would make a difference, and now I'm going to explore that avenue and if it works that will be my approach. It's frustrating when you want to do the right thing and unit test everything that you do but the tools don't support the environment that you need to work in.

Steven M. Cherry
Follow-up to this. After using NUnit for a week on my current SharePoint project, I'm sold. Everything works the way that I expect it to, and I haven't hit any roadblocks yet. The only extra thing that I would like is to be able to engage the debugger on tests from NUnit. I'm sure there's a way, though, just haven't found it yet.
Steven M. Cherry