How do I avoid using dynamic when mocking an Excel.worksheet?

Question

I'm trying to mock an Excel spreadsheet using NSubstitute or other mocking framework and MSTest (Visual Studio 2010). I'm not sure if there's a better way than this--and this doesn't quite work for testing:

Here's an example (this is all prototype code right now, and not very clean):

int[] lowerBounds = { 1, 1 };
int[] lengths = { 2, 2 };

//Initialize a 1-based array like Excel does:
object[,] values = (object[,])Array.CreateInstance(typeof(object), lengths, lowerBounds);
values[1,1] = "hello";
values[2,1] = "world";      

//Mock the UsedRange.Value2 property
sheet.UsedRange.Value2.Returns(values); 

//Test:   
GetSetting(sheet, "hello").Should().Be("world");  //FluentAssertions

So far, so good: this passes if the GetSetting method is in the same project as my test. However when GetSetting is in my VSTO Excel-Addin project, it fails with the following error on the first line of the GetSetting function:

System.MissingMethodException: Error: Missing method 'instance object [MyExcel.AddIn] Microsoft.Office.Interop.Excel.Range::get_Value2()' from class 'Castle.Proxies.RangeProxy'.

For reference, the GetSetting grabs a value from columnA in the sheet, and returns the value in columnB.

public static string GetSetting(Excel.Worksheet sheet, string settingName) {
  object[,] value = sheet.UsedRange.Value2 as object[,];
  for (int row = 1; row <= value.GetLength(1); row++) {
    if (value[1, row].ToString() == settingName)
      return value[2, row].ToString();
  }
  return "";
}

The final interesting piece is if I redefine the signature of my method as follows:
public static string GetSetting(dynamic sheet, string settingName)
it works in the VSTO project.

So what is going on, and what's the best way to do something like this?

Thanks!

Answer 1

The VS2012 update: Moq & Interop Types: works in VS2012, fails in VS2010?

First up: Something has changed: How do I avoid using dynamic when mocking an Excel.worksheet?

I encountered the same problem Mocking Excel objects using NSubstitute. The dynamic resolved the problem just as you mention. However I wanted to find the root cause.

---

When your Project has a reference to Microsoft.Office.Interop.Excel.Extensions.dll you need to check if the Embed Interop Types property is visible. If it is that means your targeting .Net 4.0 (which I could guess from the dynamic keyword).

You can leave the Test Project targeting .Net 4.0 but you need to you change the VSTO Project .Net framework back to 3.5. Then you'll probably have to do some explicit casting and fully qualify things to get rid of these errors:

C# Office Excel Interop "object does not contain definition for" errors, here are a couple of examples:

.Net 4.0:

if (tmpsheetName == xlApp.ActiveSheet.Name)

.Net 3.5 equivalent

Worksheet activeSheet = (Worksheet)xlApp.ActiveSheet;
if (tmpsheetName == activeSheet.Name)

Another example:

rn.Select();

.Net 4.0

xlApp.Selection.HorizontalAlignment = Constants.xlCenter; 
xlApp.Selection.Font.Bold = true;
xlApp.Selection.Merge();

.Net 3.5 equivalent

rn.HorizontalAlignment = Constants.xlCenter;
rn.Font.Bold = true;
rn.Merge();

---

Proceed to fix all the .Net 3.5 vs 4.0 syntax errors as per the above examples. Dont forget to remove the dynamic parameter type and replace it the original Worksheet. Finally fire up the Test again and it will pass!!!

Given all the grief I experienced with Microsoft.CSharp.DLL in this thread I am of the opinion testing VSTO .Net 4.0 projects with Mocking Frameworks doesn't work.

Answer 2

It turns out that mocking very complex COM interop objects such as the Excel object or the InDesign object using any of the castle-based frameworks (nsubstitute, ninject, etc.), does not provide enough of a performance boot. Run times for tests are still measurable in seconds. (Multiplying that out by tens or hundreds of tests makes the unit tests still too slow to run under TDD principles of testing constantly.)

Testing the Excel logic then should be considered an integration test, and as such, running against the actual Excel object should be fine, making mocking not very useful in such a scenario. Results will be far more useful testing against an actual object.

Testing to an abstraction layer placed between Excel and the application would allow for fast testing of the application logic. And testing the abstraction layer-to-excel under integration testing should suffice to thoroughly test the application.