In my post about hosted build, I discovered that if you enable code coverage on unit tests that use the Fakes framework, the unit tests fail (even though the tests pass without code coverage turned on). The error is a “ShimNotSupportedException”.

I am a huge fan of Lab Management. Being able to manage test rigs centrally (and, if you’re using Hyper-V, self-provisioning and self-servicing) is a huge productivity bonus.

I am working on some code for the TFS Tester Power Tool with my colleague Anna Russo (who just got her first MVP award!) and we’re using TFS Preview for source control and work item tracking. From the start I wanted to get some unit tests and builds up and running. The challenge for the unit testing side was that the tool works against a Team Foundation Server, so testing required some sort of mocking or faking.

So you’re sitting down planning some tests for your shiny new code, only to find that your code uses WebClient to download a file. No problem – you’ve been reading about Microsoft’s new Fakes framework, so you just right-click the System reference in your test project and select “Create Fakes” and you get a bunch of cool fakes to work with.

In a previous post about the MS Fakes framework, I made mention of some bugs that appeared in the Beta. I finally had some time to test out the same code in the RC, and I am pleased to tell you that the bugs have been fixed (well, the ones I found anyway!).

Thanks to Peter Provost for helping answer a couple of questions I had about Fakes – you can look at some of my code in my previous posts about using Fakes with the TFS API.

In Part 1, we started faking some TFS objects. We got as far as faking the TeamProjectCollection and WorkItemStore. In this post, we’ll complete the test for copying work items by providing a fake QueryHierarchy and a fake list of WorkItems.

(Here’s the link to Part 2)

I’ve just spent 4 days in Seattle at my first Global MVP Summit – it’s been great meeting a lot of the other ALM MVPs and putting faces to email addresses! It’s also been great getting an “inside scope” on some of the strategic directions that the TFS and VS product teams are taking.

Visual Studio 2010 has some amazing features for Sharepoint development, like project templates, server explorers, feature and package GUIs to name a few. So you’re tasked with creating a WebPart or a Workflow – no problem, fire up VS, create a new project and you’re coding.
However, just because you’re up and coding quickly, doesn’t mean you’re being productive (necessarily). What about requirements management? Testing? Source control? And if there’s more than 1 of you coding, what Sharepoint site do you code against? Oh wait, I forgot to mention that you need to install Sharepoint on the same machine that you have VS on to actually get the Sharepoint projects to work.