Mocking Protected Members

In this lesson, you will learn how to verify or stub internal logic encapsulated within protected methods to maintain control over your system under test without breaking encapsulation.

The Challenge of Protected Members

When you are testing a class, you often encounter protected methods that perform critical side effects or return data needed for the public method you are actually testing. Since these members aren't accessible from your test project, you cannot reach into the object to setup a specific return value or verify that a protected method was called.

While the "gold standard" is to favor composition over inheritance, sometimes you are dealing with legacy code or architectural patterns like the Template Method pattern where overriding protected behavior is necessary for successful isolation.

The Strategy: Partial Mocks and Accessors

To mock protected members, you need a way to expose them to the mocking framework without changing their visibility to public. Using Moq, we utilize the Protected() method extension. This allows you to interact with members by providing their name as a string and defining the expected behavior.

Consider a class BaseProcessor with a protected virtual string GetSensitiveData() method. To control this in a test, you create a mock of the class and configure the protected member:

[Fact]
public void Process_ShouldUseMockedProtectedData()
{
    // Arrange
    var mock = new Mock<BaseProcessor> { CallBase = true };
    
    mock.Protected()
        .Setup<string>("GetSensitiveData")
        .Returns("MockedValue");

    // Act
    var result = mock.Object.PublicExecute();

    // Assert
    result.Should().Be("MockedValue");
}

By setting CallBase = true, we ensure that the rest of the class functions normally while only hijacking the specific protected method we identified. You can similarly use Verify with the Protected() syntax to ensure that the code logic indeed triggered a specific protected call, which is vital for testing internal workflows.

Key Takeaway: Use the Protected() helper in your mocking framework to gain fine-grained control over inherited logic, ensuring your tests remain isolated even when the design relies on protected members.