Moq - Non-overridable members may not be used in setup / verification expressions

Question

I'm new to Moq. I'm mocking a PagingOptions class. Here is how the class looks like:

public class PagingOptions
    {
        [Range(1, 99999, ErrorMessage = "Offset must be greater than 0.")]
        public int? Offset { get; set; }

        [Range(1, 100, ErrorMessage = "Limit must be greater than 0 and less than 100.")]
        public int? Limit { get; set; }

        public PagingOptions Replace(PagingOptions newer)
        {
            return new PagingOptions
            {
                Offset = newer.Offset ?? Offset,
                Limit = newer.Limit ?? Limit
            };
        }
    }

Here is my mock version of the class,

var mockPagingOptions = new Mock<PagingOptions>();
            mockPagingOptions.Setup(po => po.Limit).Returns(25);
            mockPagingOptions.Setup(po => po.Offset).Returns(0);

I get the below error when setting up the property values. Am I making something wrong. Looks like I cannot Moq concrete class? Only Interfaces can be Mocked? Please assist.

Thanks, Abdul

Make the properties `Offset` and `Limit ` virtual. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/virtual — Jordan Bowker, Jul 05 '19 at 15:18
In this case it doesn't seem like there's a reason to mock this. You can just create an actual instance of `PagingOptions` and set its properties instead of using a `Mock`. Don't make anything virtual. — Scott Hannen, Jul 05 '19 at 15:18
unless this is an [XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) I see no need to mock this object. There appears to be no obvious knock on effects of using the object as is that would warrant having to create a mock — Nkosi, Jul 05 '19 at 15:22
@ScottHannen How to find which object to mock and which not to mock? how are you differentiating? — fingers10, Jul 05 '19 at 15:25

score 104 · Accepted Answer · answered Jul 05 '19 at 15:36

Moq creates an implementation of the mocked type. If the type is an interface, it creates a class that implements the interface. If the type is a class, it creates an inherited class, and the members of that inherited class call the base class. But in order to do that it has to override the members. If a class has members that can't be overridden (they aren't virtual, abstract) then Moq can't override them to add its own behaviors.

In this case there's no need to mock PagingOptions because it's easy to use a real one. Instead of this:

var mockPagingOptions = new Mock<PagingOptions>();
        mockPagingOptions.Setup(po => po.Limit).Returns(25);
        mockPagingOptions.Setup(po => po.Offset).Returns(0);

Do this:

var pagingOptions = new PagingOptions { Limit = 25, Offset = 0 };

How do we determine whether or not to mock something? Generally speaking, we mock something if we don't want to include the concrete runtime implementation in our test. We want to test one class not both at the same time.

But in this case PagingOptions is just a class that holds some data. There's really no point in mocking it. It's just as easy to use the real thing.

Although this works if these are the only properties/methods you want to test, it doesn't if you want to predict other properties/methods behavior in pagingOptions. — Luis Gouveia, Mar 31 '21 at 13:51

score 25 · Answer 2 · answered May 22 '20 at 17:56

25

I had the same error, but in my case I was trying to mock the class itself and not its interface:

// Mock<SendMailBLL> sendMailBLLMock = new Mock<SendMailBLL>(); // Wrong, causes error.
Mock<ISendMailBLL> sendMailBLLMock = new Mock<ISendMailBLL>();  // This works.

sendMailBLLMock.Setup(x =>
    x.InsertEmailLog(
        It.IsAny<List<EmailRecipient>>(),
        It.IsAny<List<EmailAttachment>>(),
        It.IsAny<string>()));

answered May 22 '20 at 17:56

Telmo Trooper

3,247
1
24
30

That helps a lot. Thank you so much. In case you want to set some operation, `obj.Setup(...).Returns(/*mock implementation*/);` ref: https://stackoverflow.com/questions/41351543/mock-a-class-in-a-class-in-a-unit-test – Devendra Lattu Jan 29 '21 at 20:43
As stupid as it seems, this was my problem as well. Helpful to double check if you are using the interface, before digging deeper what could possible have gone wrong. – typhon04 Feb 08 '21 at 08:30
Thank you!! I'd upvote more if I could – pcdev Apr 21 '21 at 02:05

score 5 · Answer 3 · answered Aug 17 '20 at 12:54

I want to improve Scott's answer and give a general answer

If the type is a class, it creates an inherited class, and the members of that inherited class call the base class. But in order to do that it has to override the members. If a class has members that can't be overridden (they aren't virtual, abstract) then Moq can't override them to add its own behaviors.

In my situation i had to make the prop virtual. So answer to your class code is:

public class PagingOptions {
    [Range (1, 99999, ErrorMessage = "Offset must be greater than 0.")]
    public virtual int? Offset { get; set; }

    [Range (1, 100, ErrorMessage = "Limit must be greater than 0 and less than 100.")]
    public virtual int? Limit { get; set; }

    public PagingOptions Replace (PagingOptions newer) {
        return new PagingOptions {
            Offset = newer.Offset ?? Offset,
                Limit = newer.Limit ?? Limit
        };
    }
}

use same:

var mockPagingOptions = new Mock<PagingOptions>();
        mockPagingOptions.Setup(po => po.Limit).Returns(25);
        mockPagingOptions.Setup(po => po.Offset).Returns(0);

yes but now you're modifying a property accessor just for testability sake — Poat, Sep 29 '20 at 16:46

No Refunds No Returns · Answer 4 · 2021-03-15T02:45:57.763

In case you reached this question based on the original title Non-overridable members may not be used in setup / verification expressions and none of the other answers have helped you may want to see if reflection can satisfy your test needs.

Suppose you have a class Foo with a property defined as public int I { get; private set; }

If you try the various methods in the answers here few of them will work for this scenario. However you can use .net reflection to setup a value of an instance variable and still keep fairly good refactoring support in the code.

Here is a snippet that sets a property with a private setter:

var foo = new Foo();
var I = foo.GetType().GetProperty(nameof(Foo.I), BindFlags.Public | BindingFlag.Instance);
I.SetValue(foo, 8675309);

I do not recommend this for production code. It has proven very useful in numerous tests for me. I found this approach a few years ago but needed to look it up again recently and this was the top search result. HTH. YMMV.

Moq - Non-overridable members may not be used in setup / verification expressions

4 Answers4

Linked

Related