Шаги, которые вы описываете, настраивают Moq для тестирования внутренних классов и членов, поэтому на самом деле не имеют ничего общего с тестированием защищенного или частного метода
Тестирование приватных методов - это неприятный запах, вам действительно нужно протестировать только публичный API. Если вы чувствуете, что метод действительно важен и нуждается в тестировании в отдельности, возможно, он заслуживает того, чтобы быть в своем собственном классе, где его можно потом протестировать самостоятельно?
Если ваше сердце настроено на тестирование защищенного метода, описанного выше, вы можете свернуть свой собственный макет в своей тестовой сборке:
public class CustomerServiceMock : CustomerService {
public void DoSomethingTester() {
// Set up state or whatever you need
DoSomething();
}
}
[TestMethod]
public void DoSomething_WhenCalled_DoesSomething() {
CustomerServiceMock serviceMock = new CustomerServiceMock(...);
serviceMock.DoSomethingTester();
}
Если бы это было личное, вы, вероятно, могли бы сделать что-то хитрое с отражением, но идти по этому пути - путь к испытанию ада.
Обновление
Пока вы приводите пример кода в своем вопросе, я не вижу, как вы хотите «протестировать» защищенный метод, поэтому я придумаю что-то придуманное ...
Допустим, ваша служба поддержки выглядит так: -
public CustomerService : ICustomerService {
private readonly ICustomerRepository _repository;
public CustomerService(ICustomerRepository repository) {
_repository = repository;
}
public void MakeCustomerPreferred(Customer preferred) {
MakePreferred(customer);
_repository.Save(customer);
}
protected virtual void MakePreferred(Customer customer) {
// Or more than likely some grungy logic
customer.IsPreferred = true;
}
}
Если вы хотите проверить защищенный метод, вы можете просто сделать что-то вроде: -
[TestClass]
public class CustomerServiceTests {
CustomerServiceTester customerService;
Mock<ICustomerRepository> customerRepositoryMock;
[TestInitialize]
public void Setup() {
customerRepoMock = new Mock<ICustomerRepository>();
customerService = new CustomerServiceTester(customerRepoMock.Object);
}
public class CustomerServiceTester : CustomerService {
public void MakePreferredTest(Customer customer) {
MakePreferred(customer);
}
// You could also add in test specific instrumentation
// by overriding MakePreferred here like so...
protected override void MakePreferred(Customer customer) {
CustomerArgument = customer;
WasCalled = true;
base.MakePreferred(customer);
}
public Customer CustomerArgument { get; set; }
public bool WasCalled { get; set; }
}
[TestMethod]
public void MakePreferred_WithValidCustomer_MakesCustomerPreferred() {
Customer customer = new Customer();
customerService.MakePreferredTest(customer);
Assert.AreEqual(true, customer.IsPreferred);
}
// Rest of your tests
}
Имя этого "шаблона" - специфичный для Test подкласс (основанный на терминологии тестовых шаблонов xUnit) для получения дополнительной информации, которую вы можете увидеть здесь: -
http://xunitpatterns.com/Test-Specific%20Subclass.html
Судя по вашим комментариям и предыдущему вопросу, вам кажется, что вам поручено внедрить модульные тесты для какого-то устаревшего кода (или вы приняли решение самостоятельно). В этом случае библия всех вещей унаследованного кода - это книга Майкла Фезерса. Он охватывает такие методы, как рефакторинг и методы, позволяющие разбить «непроверяемые» классы и методы на нечто более управляемое, и я настоятельно рекомендую это.