Getting Typemock Isolator running within a TFS 2012 build – part 2

I posted previously on getting Typemock 7.x running in a TFS 2012 RC build process . Well it seems the activities I previously published did not work on the TFS 2012 RTM build i.e if you do nothing other than upgrade your TFS server from RC to RTM a previously working build fails, no attempt was made to run any tests and I got the unhelpful error

TF900546: An unexpected error occurred while running the RunTests activity: ‘Executor process exited.’.

Note: TF900546 seems to be the generic – test failed error number. If you see it you will usually have to look elsewhere for anything helpful.

So I assumed that the problem must be some difference with the TeamFoundation assemblies I was referencing between the RC and RTM versions, so I rebuilt my activities, all to no effect, I got the same error. So I did some more digging into the code. I found a number of issues, why these had not caused an issue before I don’t know:

Target property

If you do not specify a .NET version via the Target property of the TypeMockRegister activity it does not attempt to start interception. As setting this property every time you want to use the activity is a pain, I modified the activity so that if no Target property is passed then the value v4.0.30319 is used, the version of .NET 4.5 as it appears in the c:\windows\Microsoft.Net\framework folder.

Note Missing of the leading v if the Target value causes the TFS build agent to hang, I have no idea why.

Once this change was made the build ran and it tried to run all my tests, but the ones involving Typemock failed, with the message

Test method BuildProcessValidation.Tests.MSTestTypemockTests.DirtyTrickMockingWithTypemock_Email_is_sent_when_client_order_is_processed threw exception:
System.TypeInitializationException: The type initializer for ‘f5’ threw an exception. —> System.TypeInitializationException: The type initializer for ‘TypeMock.InterceptorsWrapper’ threw an exception. —> TypeMock.TypeMockException:
*** Typemock Isolator needs to be linked with Coverage Tool to run, to enable do one of the following:
   1. link the Coverage tool through the Typemock Isolator Configuration
   2. run tests via TMockRunner.exe -link
   3. use TypeMockStart tasks for MSBuild or NAnt with Link
For more information consult the documentation (see Code Coverage with Typemock Isolator topic)

On looking in the build box’s event log I saw the message

.NET Runtime version 4.0.30319.17929 – Loading profiler failed during CoCreateInstance.  Profiler CLSID: ‘{B146457E-9AED-4624-B1E5-968D274416EC}’.  HRESULT: 0x8007007e.  Process ID (decimal): 2068.  Message ID: [0x2504].


Basically the issue was the Typemock interceptor, the profiler, was not being started because Typemock was not installed on the build box. To prove this I manually installed Typemock on the build box and the error went away, all my tests ran. So happy my activity basically worked, I removed Typemock from the build box and the problem returned, so I know I had an autodeployment issue.

On checking the activity code again I found I was not handling the nullable boolean correctly for the AutoDeploy build argument of the type TypemockSettings. As soon as this was fixed and deployed by build leapt into life.

In summary

So I am please to say I have a working activity again, as I said in my previous post I see this as stopgap measure until Typemock Release their official version. This set of activities have had minimal testing and I am not sure the undeploy logic is working fully, but as I don’t need this feature I am not worrying about it for now.

Hope you find it useful in its current state.

Using an internal Nuget server to manage the Typemock assembly references.

In my last post I discussed the process I needed to go through to get Typemock Isolator running under TFS 2012. In this process I used the Auto Deploy feature of Isolator. However this raised the  question of how to manage the references within projects. You cannot just assume the Typemock assemblies are in the GAC, they are not on the build box using auto deploy. You could get all projects to reference the auto deployment location in source control. However, if you use build process templates across projects it might be you do not want to have production code referencing build tools in the build process are directly.

For most issues of this nature we now use Nuget. At Black Marble we make use of the public Nuget repository for tools such as XUnit, SpecFlow etc. but we also have an internal Nuget repository for our own cross project code libraries. This includes licensing modules, utility and data loggers etc.

It struck me after writing the last post that the best way to manage my Typemock references was with a Nuget package, obviously not a public one, this would be for Typemock to produce. So I create one to place on our internal Nuget server that just contained the two DLLs I needed to reference (I could include more but we usually only need the core and act assert arrange assemblies).

[Update 6th Aug PM] – After playing with this today seems I need the following in my Nuget package


If you miss out the configuration.dll it all works locally on a developers PC, but you get a ‘cannot load assembly error’ when trying to run a TFS build with Typemock auto deployment. Can’t see why obviously but adding the reference (assembly to the package) is a quick fix.



IT IS IMPORANT TO NOTE that using a Nuget package here in no way alters the Typemock licensing. Your developers still each need a license, they also need to install Typemock Isolator, to be able to run the tests and your build box needs to use auto deployment. All using Nuget means is that you are now managing references in the same way for Typemock as any other Nuget managed set of assemblies. You are internally consistent, which I like.

So in theory as new versions of Typemock are released I can update my internal Nuget package allowing projects to use the version they require. It will be interesting to see how well this works in practice.

Getting Typemock Isolator running within a TFS 2012 build

Update 23rd Aug 2012: This blog post was produced testing against the 2012RC, seems it does not work against the 2012 RTM release. I am seeing the error in my build logs

 TF900546: An unexpected error occurred while running the RunTests activity: ‘Executor process exited.

I am looking into this, expect to see a new blog post soon

Update 24th Aug 2012: I have fixed the issues with TFS2012RTM, the links to zip containing a working version of the activity in this post should now work. For more details see my follow up part 2 post

I have posted in the past about getting Typemock Isolator to function within the TFS build process. In TFS 2008 it was easy, you just ran a couple of MSBUILD tasks that started/stopped the Typemock Isolator inception process (the bit that does the magic other mocking frameworks cannot do). However with TFS 2010’s move to a windows workflow based build model it became more difficult. This was due to the parallel processing nature of the 2010 build process, running a single task to enable interception cannot be guaranteed to occur in the correct thread (or maybe even on the correct build agent). So I wrote wrapper build activity for MStest to get around this problem. Howerver, with the release of Typemock Isolator 6.2 direct support for TFS 2010 was added and these TFS build activities have been refined in later releases. In the current beta (7.0.8) you get a pre-created TFS build process template to get you going and some great auto deploy features, but more of that later.

The problem was I wanted to put Isolator based tests within a TFS 2012 build process. I posted before about my initial thoughts on the problem. The main problem is that TFS build activities have to be built against the correct version of the TFS API assemblies (this is the reason the community custom activities have two sets of DLLs in the release ZIP file). So out the box you can’t use the Typemock.TFS2010.DLL with TFS 2012 as it is built against the 2010 API.

Also you cannot just use the Typemock provided sample build process template. This is built against 2010 too, so full of 2010 activities which all fail.

What I tried that did not work (so don’t waste your time)

So I took a copy of the default TFS 2012 build process template and followed the process to add the Typemock.TFS2010.DLL containing the Typemock activities to the Visual Studio 2012 toolbox (the community activity documentation provides a good overview of this strangely complex process also see the ALM Rangers guidance). I then added the TypemockRegister and TypemockStart activities at the start of the testing block. For initial tests I did not both adding the TypemockStop activity


I then made sure that

  • Typemock was installed on the build agent PC
  • The Typemock.TFS2010.dll was in the correct CustomActivities folder in source control
  • The build controller was set to load activities from the CustomActivities folder.

However, when I tried to queue this build I got an error 

Exception Message: Object reference not set to an instance of an object. (type NullReferenceException)
Exception Stack Trace:    at TypeMock.CLI.Common.TypeMockRegisterInfo.Execute()


The issue was that though Typemock was installed, the required DLLs could not be found. Checking in a bit more detailed (by running the build with diagnostic level of logging and using Fuslogvw) I saw it was trying load the wrong versions of DLLs as expected. So the first thing I tried to use was binding redirection (a technique I used before with similar Typemock). This in effect told the Typemock activity to use the 2012 DLLs when it asks for the 2010 ones. This is done by using an XML config file (Typemock.TFS2010.DLL.config)  in the same folder as the DLL file.

      <assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>
         <assemblyIdentity name=”Microsoft.TeamFoundation.Build.Workflow”
                           culture=”neutral” />
         <bindingRedirect oldVersion=”″
         <assemblyIdentity name=”Microsoft.TeamFoundation.Build.Client”
                           culture=”neutral” />
         <bindingRedirect oldVersion=”″
          <publisherPolicy apply=”no”>

I first tried to add this file to the CustomActivities source control folder, where the custom activities are loaded from by the build agent, but that did not work. I could only get it to work if I put both the DLL and the config files in the  C:\Program Files\Microsoft team Foundation Server 1.0\Tools folder on the build agent. This is not a way I like to work, too messy having to fiddle with the build agent file system.

Once this setting was made I tried a build again and got the build process to load, but the TypemockRegister activity failed as the Typemock settings argument was not set. Strangely Typemock have chosen to pass in their parameters as a complex type (of the type TypemockSettings) as opposed to four strings. Also you would expect this argument to be passed directly into their custom activities by getting activity properties to argument values, but this is not how it is done. The Typemock activities know to look directly for an argument called Typemock. This does make adding the activities easier, but not obvious if you are not expecting it. So I added this argument to the build definition in Visual Studio 2012 and checked it in, but when I tried to set the argument value for a specific build it gave the error that the DLL containing the type Typemock.TFS2010.TypemockSettings could not be loaded, again the TFS 2010/2012 API issue, this time within Visual  Studio 2012




At this point I gave up on binding redirection, I had wasted a lot more time than this post makes it sound. So I removed all the work I had previously done and thought again.

What did work

I decided that the only sensible option was to recreate the functionality of the Typemock activity against the 2012 API. So I used Telerik JustDecompile to open up the Typemock.Tfs2010.dll assembly and had a look inside. In Visual Studio 2012 I then created a new C# class library project called Typemock.BM.TFS20102 targeting .NET 4. I then basically cut and pasted the classes read from JustDecompile into classes of the same name in the new project. I then added references to the TFS 2012 API assemblies and any other assemblies needed and compiled the project. The one class I had problems with the TypemockStart, specifically the unpacking of the properties in the InternalExecute method. The reflected code by JustDecompile was full of what looked to be duplicated array copying which did not compile. So I simplified this to map the properties to the right names.

You can download a copy of my Typemock.BM.TFS2012.Dll from here, so you don’t have to go through the process yourself.

I now had a TFS 2012 custom build activity. I took this new activity and put it the CustomActivities folder. Next I took an unedited version of the default 2012 build process template and added these new Typemockregister, TypemockStart (at the start of the test block) and TypemockStop (at the end of the test block) activities as well as a Typemock argument (of TypemockSettings type). I checked this new template into TFS, and then created a build setting the Typemock argument settings.



Now at this point it is worth mentioning the nice feature of AutoDeploy. This allows you to use Typemock without having it installed on the build agent, thus making build agent management easier. You copy the AutoDeploy folder from the Typemock installation folder into source control (though a rename might be sensible so you remember it is for Typemock auto deployment and not anything else). You can then set the four argument properties

  • The location of the auto deployment folder in source control
  • A switch to enable auto deployment
  • Your Typemock license settings.

By using the auto deployment feature I was able to uninstall Typemock on the build agent.

So I tried a build using these setting, all the build activities loaded Ok and the TypemockSettings was read, but my project compile failed. As I had uninstalled Typemock on my build agent all the references to Typemock assemblies in the GAC failed. These references were fine on a development PC which had Typemock installed not on the build agent which did not.

So I needed to point the references in my project to another location. Typemock have thought of this too and provide a tools to remap the references that you can find on the Typemock menu


You can use this tool, or do it manually.

You could re-point the references to the same location you used for the AutoDeploy feature. However I prefer to keep my project references separate to my infrastructure (build activities etc.) as I use the same build templates cross project. For our projects we arrange source control so we have the structure in the general form (ignoring branch for simplicity)

A team project
                   [Nuget packages]
                   other assemblies
                   [Nuget packages]
                   other assemblies

I make sure we put all assemblies referenced in the lib folder, including those from Nuget using a nuget.config file in the src folder with the SLN file e.g.


This structure might not be to your taste, but I like it as it means all projects are independent, and so is the build process. The downside is you have to manage the references for the projects and build separately, but I see this as good practice. You probably don’t share want to reference and Nuget packages between separate projects/solutions.

So now we have a 2012 build process that can start Typemock Isolator, and a sample project that contains Typemock based tests, some using MSTest and some using XUnit (remember Visual Studio 2012 support multiple unit testing frameworks not just MSTest, see here on how to set this up for TFS build). When the build is run I can see all my unit tests pass to Typemock isolator must be starting correctly



So for me this is a reasonable work around until Typemock ship a TFS 2012 specific version. Hope this file saves you some time if you use Typemock and TFS 2012.

Why Typemock Isolator does not work on TFS 2012 Build and what you can do about it

Update 4/Aug/2012: See post on my implementation of a 2012 version of this activity

If you are using Typemock Isolator in your unit testing then you be wanting to include then in your automated build process. Unlike other mocking frameworks you have to do a bit of work to achieve this with Isolator, this is because to enable its advanced features of mocking items like sealed private classes you have to start the interceptor that does the magic prior to running the tests and the switch it off afterwards.

In the past I posted on how you could use a build activity I wrote to wrapper MStest in a TFS 2010 build using TMockRunner. Since I wrote this Typemock released a set of build activities to do the starting and stopping of the inceptor as separate activities, a much more flexible solution which I would always recommend for TFS.

However when you try to use either with TFS 2012 you get a problem, the activities fail to load. This is a problem we saw on the TFS Extensions Codeplex project; you have to build you activities against either the 2010 TFS API or the 2012 TFS API. You don’t need to alter the code in your activities, but you do need to make a specific build.

So at this time there is no solution, one or both of these activities need to be rebuilt. For the MSTest wrapper I wrote the source is available so you can do it yourself if you want to, but the way Typemock have implemented their activities is a better solution. This is because it is not reliant on TMockRunner and MStest, it can wrapper any activities. This is important as to be able to use the new ‘any framework’ unit testing features in VS2012 you want to use Microsoft’s new test running activities and not just the old MSTest activity.

I understand that Typemock are looking at releasing a TFS2010 version of their activities soon, but I know of no release date as yet. If you want an immediate solution you will need to do a bit of work.

  • You could rebuild my MSTest based activity
  • You could use the standard InvokeMethod activity and put the contents of my MStest activity’s generated command line into this
  • But the one I favour is to use a dissembler such as Telerik JustDecompile to get the code from the Typemock.TFS2010.DLL and build a new activity.

However, it must be said I see this as just a temporary measure until the official Typemock 2012 activity is released. I am not sure I will get around to doing this before the Typemock release, we shall see.

Fix for problem faking two SPLists in a single unit test with Typemock Isolator has been released

A blogged a while ago about a problem faking multiple SPList with Typemock Isolator in a single test. With the release of Typemock Isolator you no longer have to use the workaround I documented.

You can now use the code if the originally planned, and it works as expected

   1: public partial class TestPage : System.Web.UI.Page
2: {
3: public TestPage()
4: {
5:  var fakeWeb = Isolate.Fake.Instance<SPWeb>();

7: Isolate.WhenCalled(() => SPControl.GetContextWeb(null)).WillReturn(fakeWeb);
9: // return value for 1st call
10: Isolate.WhenCalled(() => fakeWeb.Lists["Centre Locations"].Items).WillReturnCollectionValuesOf(CreateCentreList());
11: // return value for all other calls
12: Isolate.WhenCalled(() => fakeWeb.Lists["Map Zoom Areas"].Items).WillReturnCollectionValuesOf(CreateZoomAreaList());
13: }
15: private static List<SPListItem> CreateZoomAreaList()
16: {
17: var fakeZoomAreas = new List<SPListItem>();
18: fakeZoomAreas.Add(CreateZoomAreaSPListItem("London", 51.49275, -0.137722222, 2, 14));
19: return fakeZoomAreas;
20: }
22: private static List<SPListItem> CreateCentreList()
23: {
24: var fakeSites = new List<SPListItem>();
25: fakeSites.Add(CreateCentreSPListItem("Aberdeen ", "1 The Road, Aberdeen ", "", "", "1111", "2222", 57.13994444, -2.113333333));
26: fakeSites.Add(CreateCentreSPListItem("Altrincham ", "1 The Road, Altrincham ", "", "", "3333", "4444", 53.38977778, -2.349916667));
27: return fakeSites;
28: }
30: private static SPListItem CreateCentreSPListItem(string title, string address, string email, string url, string telephone, string fax, double lat, double lng)
31: {
32: var fakeItem = Isolate.Fake.Instance<SPListItem>();
33: Isolate.WhenCalled(() => fakeItem["Title"]).WillReturn(title);
34: Isolate.WhenCalled(() => fakeItem["Address"]).WillReturn(address);
35: Isolate.WhenCalled(() => fakeItem["Email Address"]).WillReturn(email);
36: Isolate.WhenCalled(() => fakeItem["Site URL"]).WillReturn(url);
37: Isolate.WhenCalled(() => fakeItem["Telephone"]).WillReturn(telephone);
38: Isolate.WhenCalled(() => fakeItem["Fax"]).WillReturn(fax);
39: Isolate.WhenCalled(() => fakeItem["Latitude"]).WillReturn(lat.ToString());
40: Isolate.WhenCalled(() => fakeItem["Longitude"]).WillReturn(lng.ToString());
41: return fakeItem;
42: }
44: private static SPListItem CreateZoomAreaSPListItem(string areaName, double lat, double lng, double radius, int zoom)
45: {
46: var fakeItem = Isolate.Fake.Instance<SPListItem>();
47: Isolate.WhenCalled(() => fakeItem["Title"]).WillReturn(areaName);
48: Isolate.WhenCalled(() => fakeItem["Latitude"]).WillReturn(lat.ToString());
49: Isolate.WhenCalled(() => fakeItem["Longitude"]).WillReturn(lng.ToString());
50: Isolate.WhenCalled(() => fakeItem["Radius"]).WillReturn(radius.ToString());
51: Isolate.WhenCalled(() => fakeItem["Zoom"]).WillReturn(zoom.ToString());
52: return fakeItem;
53: }
55: }

A check of the returned values shows

  • web.Lists["Centre Locations"].Items.Count returns 2
  • web.Lists["Map Zoom Areas"].Items.Count) returns 1

More thoughts on Typemock Isolator, Microsoft Fakes and Sharepoint

I posted yesterday on using Typemock and Microsoft Fakes with SharePoint. After a bit more thought I realised the key thing in using Typemock I found easier was the construction of my SPListItem dataset. Typemock allowed me to fake SPListItems and put them in a generic List<SPListItem> then just make this the return value for the Item collection using the magic .WillReturnCollectionValuesOf() method that converts my List to the required collection type. With the Microsoft Fakes I had think about a delegate that constructed my test data at runtime. This is not a problem, just a different way of working.

A side effect of using the Typemock .WillReturnCollectionValuesOf() method is that if I check the number of SPListItems in the return SPListColection I have a real collection so I can use the collection’s own .Count method, I don’t have fake it out. With the Microsoft Fakes as there is no collection returned so I must Fake its return value.

This is a trend common across Typemock Isolator, it does much  of the work for you. Microsoft Fakes, like Moles, required you to do the work. In Moles this was addressed by the use of behaviour packs to get you started with standard items you need in SharePoint.

I would say again that there may be other ways of using the Microsoft Fakes library, so there maybe ways to address these initial comments of mine, I am keen to see if this is the case

Now that VS11 has a fake library do I still need Typemock Isolator to fake out SharePoint?

Updated 5 May 2012 Also see my follow up post, this corrects some of the information of faking SharePoint 

I have done posts in the past about how you can use Typemock Isolator to fake out SharePoint to speed design and testing. The  reason you need special tooling, beyond standard mocking frameworks like Rhino or MOQ, is that SharePoint has many sealed private classes with no public constructors. So in the past you only had two options: Typemock Isolator and Moles from Microsoft research.

With the release of the Visual Studio 11 beta we now have a means to fake out ‘non mockable classes’ (shim) classes that is shipped in the box. This tooling I understand has it roots in Moles, but is all new. So with the advent of fakes in VS11 you have to ask ‘do I still need Typemock isolator?”

To answer this question I have tried to perform the same basic mocking exercise as I did in my previous posts. Create a fake SharePoint list and make sure I can access the faked out content in test asserts.

In Typemock Isolator

To perform the test in Isolator, assuming Isolated is installed on your PC, is add a reference to Typemock.dll and Typemock.ArrangeActAssert.dll and use the following code

[TestMethod]         public void FakeSharePointWithIsolator()         {              // Arrange // build the dataset var fakeItemList = new List<SPListItem>();             for (int i = 0; i < 3; i++)             {                 var fakeItem = Isolate.Fake.Instance<SPListItem>();                 Isolate.WhenCalled(() => fakeItem.Title).WillReturn(String.Format("The Title {0}", i));                 Isolate.WhenCalled(() => fakeItem["Email"]).WillReturn(String.Format("email{0}@fake.url", i));                  fakeItemList.Add(fakeItem);             }              // fake the SPWeb and attach the data var fakeWeb = Isolate.Fake.Instance<SPWeb>();             Isolate.WhenCalled(() => fakeWeb.Url).WillReturn("http://fake.url");             Isolate.WhenCalled(() => fakeWeb.Lists["fakelistname"].Items).WillReturnCollectionValuesOf(fakeItemList);               // act // not actually doing an operation // assert Assert.AreEqual("http://fake.url", fakeWeb.Url);             Assert.AreEqual(3, fakeWeb.Lists["fakelistname"].Items.Count);              Assert.AreEqual("The Title 0", fakeWeb.Lists["fakelistname"].Items[0].Title);             Assert.AreEqual("email0@fake.url", fakeWeb.Lists["fakelistname"].Items[0]["Email"]);             Assert.AreEqual("The Title 1", fakeWeb.Lists["fakelistname"].Items[1].Title);             Assert.AreEqual("email1@fake.url", fakeWeb.Lists["fakelistname"].Items[1]["Email"]);                      }

Using Microsoft Faking

Adding the Fake

The process to added a fake in VS11 is to right click on an assembly reference (in our case Microsoft.SharePoint) and select the ‘add fake assembly’ option.


You should see a Fake reference created and an entry in the fakes folder


Gotcha Warning ‘Can’t generate the fake reference’ – When I tried to generate a fake for the Microsoft.SharePoint assembly within a classlibrary project that had a reference to only the Microsoft.Sharepoint assembly (and the default assemblies references added for any classlibrary project) the entry is made in the Fakes folder but no .Fakes assembly is created. After a delay (30 seconds?)  you see an error message in the Visual Studio output window. This tells you a reference cannot be resolved, if you delete the entry in the Fakes folder, add the missing reference listed in the output windows and repeat the process you get the same problem but another assembly is named as missing, add this and repeat this process. Eventually the .Fakes assembly is created.

In the case of this SharePoint sample I had to manually add Microsoft.SharePoint.Dsp, Microsoft.SharePoint.Library, Microsoft.SharePoint.Search, System.Web, System.Web.ApplicationServices. Remember these entries are ONLY required to allow the fake creation/registration, they are not needed for your assembly to work in production or for Typemock.  [5 May 2012 See my follow up post

You should now have a generated assembly that you can use to create your fakes shims

Writing the fakes logic

The logic to create the fake behaviour is as follows. Now there might be easier ways to do this, but this does work and is reasonably readable

 [TestMethod] public void FakeSharePointWithShims() 
using (ShimsContext.Create()) // required to tidy up the shim system
// arrange
var fakeWebShim = new Microsoft.SharePoint.Fakes.ShimSPWeb()
UrlGet = () =>
ListsGet = () =>
new Microsoft.SharePoint.Fakes.ShimSPListCollection()
ItemGetString = (listname) =>
new Microsoft.SharePoint.Fakes.ShimSPList()
ItemsGet = () =>
new Microsoft.SharePoint.Fakes.ShimSPListItemCollection()
// we have to fake the count, as we not returning a list SPListCollection
CountGet = () => 3,
ItemGetInt32 = (index) =>
new Microsoft.SharePoint.Fakes.ShimSPListItem()
TitleGet = () =>
string.Format("The Title {0}", index),
ItemGetString = (fieldname) =>
string.Format("email{0}@fake.url", index)
// note we don't check the field name

// act
// not actually doing an operation
// assert
var fakeWeb = fakeWebShim.Instance;
Assert.AreEqual("http://fake.url", fakeWeb.Url);
Assert.AreEqual(3, fakeWeb.Lists["fakelistname"].Items.Count);
Assert.AreEqual("The Title 0", fakeWeb.Lists["fakelistname"].Items[0].Title);
Assert.AreEqual("email0@fake.url", fakeWeb.Lists["fakelistname"].Items[0]["Email"]);
Assert.AreEqual("The Title 1", fakeWeb.Lists["fakelistname"].Items[1].Title);
Assert.AreEqual("email1@fake.url", fakeWeb.Lists["fakelistname"].Items[1]["Email"]); }



Which which do you find the most readable?

I guess it is down to familiarity really. You can see I end up using the same test asserts, so the logic I am testing is the same.

I do think the Typemock remains the easier to use. There is the gotcha I found with having to add extra references to allow the fakes to be create in the VS11 faking system, and just the simple fact of having to manually create the fakes in Visual Studio, as opposed to it just being handled behind the scenes by Typemock. There is also the issue of having to refer to the ShimSPWeb class and using the .Instance property as opposed to just using the SPWeb in Typemock.

The down side of Typemock is the cost and the need to have it installed on any development and build machines, neither an issue for the Microsoft fake system, the tests just being standard .NET code that can be wrappered in any unit testing fame work (and remember VS11’s Unit Test Explorer and TFS11 build allow you to use any testing framework not just MStest.

So which tool am I going to use? I think for now I will be staying with Typemock, but the VS11 faking system is well worth keeping an eye on.

[Updates 24 March 12 – More comments added in a second post]

Typemock Isolator Version 7

Whilst travelling I had neglected to post about the new release of Typemock Isolator Version 7. This new release extends the range of the product to provide a variety of ‘test support tools’ that help you track down bugs sooner.

However, the best new feature for me is that it allows support of historic versions of Isolator, this means you don’t have to upgrade all projects to V7 at the same time. The V7 engine will use the older assemblies  e.g. V6 perfectly happily. Make managing build boxes far easier