6

I want to mock the Microsoft.Office.Interop.Excel.Range (and the other Microsoft.Office.Interop.Excel interfaces) to unit test my application. I'm using Moq 4.0.10827 with .NET 4 in C#.

In my unit test, I attempt to set up the behavior of the mock as follows:

        var range = new Mock<Microsoft.Office.Interop.Excel.Range>();
        range.Setup(r => r.get_Value(1)).Returns("Something");

        var classBeingTested = new MyClass(range.Object);

In the code being unit tested, I'm using the Range as follows:

    public MyClass(Range range)
    {
        var value = range[1].ToString();
    }

When the test runs, it produces the following exception:

        Error: Missing method 'instance object [My.Example.Implementation.MyClass] Microsoft.Office.Interop.Excel.Range::get__Default(object,object)' from class 'Castle.Proxies.RangeProxy'.

How can I implement this mocking successfully? I realize that isolating the Excel Interop functionality with a pattern such as https://stackoverflow.com/a/9486226/1548950 is a potential solution; however, I'd be happier with being able to create mocks from the Microsoft.Office.Interop.Excel interfaces.

EDIT: More details on this issue

OK, this is strange. I've created a project to test the suggestion by jimmy_keen. It works. However, when I use the same suggestion to test the project I had issues with, it throws the following exception:

Error: Missing method 'instance object [My.Example.Implementation.MyClass] Microsoft.Office.Interop.Excel.Range::get__Default(object,object)' from class 'Castle.Proxies.RangeProxy'.

Since jimmy_keen's suggestion worked fine on other projects, I started suspecting that there is something wrong with the project I'm testing the code with. So, I created a test solution that demonstrates the problem in detail: http://www7.zippyshare.com/v/70834394/file.html

The root of the problem seems to be that the project contains another class (that is not being unit tested) with essentially the following code:

using Microsoft.Office.Interop.Excel;
namespace Project
{
    public class UnTestedClass
    {
        public UnTestedClass(Worksheet sheet)
        {
            var foo = sheet.Range["Description"].Column;
        }
    }
}

I don't understand why this causes the issue, because I'm not using UnTestedClass in the unit test at all. Am I missing something in how I should use Moq, or have I stumbled upon a bug?

Community
  • 1
  • 1
Lauri Harpf
  • 1,448
  • 1
  • 12
  • 30
  • +1 This is strange, I'm guessing it has something to do with COM objects. As soon as I reference the excel interop, I can no longer reference my Moq library... Weird... – jsmith Jul 24 '12 at 14:51
  • After some work on this, I'm now moving towards isolating the Microsoft.Office.Interop.Excel functionality with my own custom classes & interfaces instead of mocking Microsoft.Office.Interop.Excel.* directly. While the answer to this question does solve the immediate issues, mocking Microsoft.Office.Interop.Excel.* ultimately just begun to require too much setup work to make it useful. – Lauri Harpf Aug 03 '12 at 05:52

1 Answers1

5

Your code accesses indexer, and that's what you need to mock:

var range = new Mock<Microsoft.Office.Interop.Excel.Range>();
range.Setup(r => r[1, It.IsAny<object>()]).Returns("something");

Note that Range indexer actually takes two parameters - hence the It.IsAny<object>() constraint in call.

k.m
  • 30,794
  • 10
  • 62
  • 86
  • Thanks, I tested this and it does work in some cases. However, the unit test I'm working on still stubbornly refuses to work. Please see the test solution I've uploaded at http://www7.zippyshare.com/v/70834394/file.html – Lauri Harpf Jul 25 '12 at 07:13
  • 2
    @LauriHarpf: this is interesting. Apparently it's an "issue" with compiler generated code. The `Range` type interface generated by compiler in your *Project* has extra property (`Column`, namely). I have no clue how this could be problematic for Castle... but it's COM. If you'll check your assemblies with ILSpy for example, you'll see what I mean. The compiler generated code differs (even tho classes are the same) and this must be the issue. Note that if you stub `range.Setup(r => r.Column).Returns(0);` this test will also pass. – k.m Jul 25 '12 at 21:58
  • 1
    Excellent, thanks! The ILSpy tip was golden as well; in my real project, I see other extra properties appearing in addition to Column. Present are "Column", "Columns", "Row", "Rows" and "Value". This behavior will probably make any unit tests I write quite brittle, because at any time new properties might appear and break something.. In any case, by using your tips and carefully mocking all the extra properties this works, so marking as answer. Thank you, sir! – Lauri Harpf Jul 27 '12 at 11:52