Cannot use SetupGet on protected virtual property in other project

[netmajor]

MogProtecktedTest.zip

I have simple class in one project:

  public class Class1
    {
        protected internal virtual string x
        {
            get { return "dw"; }
        }
    }

and I am testing that code in other project :

    [TestFixture]
    public class tests
    {
        protected Mock<Class1> _bizLogicMock;

        [SetUp]
        public void Init()
        {
            _bizLogicMock = new Mock<Class1>() {CallBase = true};
        }

        [Test]
        public void Should_Remove_Customer_Number_When_Account_Exist()
        {
            _bizLogicMock.SetupGet(p => p.x);
        }
    }

I have error : "CS0122 'Class1.x' is inaccessible due to its protection level" on this line " _bizLogicMock.SetupGet(p => p.x);"

When I have that class in same project it works.
I have attached project.

[lampidudelj]

Try this..

// at the top of the test fixture
using Moq.Protected;

//in your test use Protected() extension

[Test]
public void Should_Remove_Customer_Number_When_Account_Exist()
{
bizLogicMock.Protected().SetupGet<string>("x");
}
`

[netmajor]

Hi,
I know that this will work, but I am trying to not use referencing property by string, it is not good practice

[stakx]

@netmajor: @lampidudelj has already pointed out that this is what .Protected() is there for.

Apart from that, since you've defined Class1.x as protected internal, you can try placing a [assembly: InternalsVisibleTo("YourTestProject")] in the project that defines Class1 in order for your test assembly to gain access to the other assembly's internal members. Not sure whether that is any better practice, though. (Btw. it is due to the internal access modifier that your test compiles when Class1 is in the same assembly.)

Fundamentally, you just cannot bypass normal C# language rules, and neither can Moq. If you declare a property protected, that's what you're going to get. Any attempts to make it publicly accessible (which goes against its definition) probably won't be pretty, no matter what.

I am going to close this issue since it's really more a question about regular .NET and C# type member visibility rules than it is about Moq (which already provides what it can).