Незаменимое тестирование, если был вызван метод частного класса

Question

Не имею большого опыта в тестировании, пытаясь изменить это, тестируя библиотеки, которые я недавно сделал.

Использование для этого nunit с nsubstitute.

Итак, у меня есть такой класс:

class MyClassToTest {
    private ISomeOtherClass MyPrivateClass { get;set }

    public MyClassToTest() {
        MyPrivateClass = new SomeOtherClass();
    }

    public void DoSomething() {
        MyPrivateClass.SayHello();
    }
} 

Теперь тест для метода DoSomething будетчтобы увидеть, был ли метод SayHello() на самом деле вызван на экземпляре ISomeOtherClass.

Проблема в том, что он закрытый, и при поиске лучшего способа проверить это единственное, что подошло, этосделайте свойство внутренним и установите InternalsVisibleToAttribute для сборки, в которой находятся тесты.

Пока это решение работает и внешний интерфейс для моей библиотеки все еще в порядке, правильный метод доступа для этого свойства в контекстебиблиотека все равно будет закрытой.

Тест, который я напишу, состоит в том, чтобы сделать его целочисленным:

public void MyTest() {
    var objPrivateClass = Substitute.For<ISomeOtherClass>();

    var obj = new MyClassToTest();
    obj.MyPrivateClass = objPrivateClass;
    obj.DoSomething();


    objPrivateClass.Received().SayHello();
}

Есть ли лучший способ проверить это без необходимости изменять исходный кодсделать его тестируемым?

Это может быть установка InternalsVisibleToAttribute, и сделать внутреннее свойство правильным, но пару часов назад я не знал о существовании InternalsVisibleToAttribute так думал, что лучше спросить :) 1024 *

Answer 1

Чтобы ответить на точный вопрос, Вы можете использовать рефлексию для привлечения частных пользователей, но это хрупкое и довольно медленное решение.

Лучший совет, который я могу вам дать, это то, что личноевещи должны оставаться частными;проверить поведение объекта через открытый интерфейс .Так что, если он слишком велик и его сложно протестировать, просто сделайте рефакторинг, чтобы он был тестируемым.Подумайте о Принципе единой ответственности и Принципе инверсии .

Редактировать 1 .: Вы, вероятно, ищете концепцию Внедрение зависимости .Это должно быть хорошо в большинстве случаев;однако, когда мы говорим о библиотеках многократного использования (вы упомянули, что делаете библиотеку), другие решения могут лучше подойти для пользователей вашей библиотеки (например, создание Фасада или переосмысление вашего дизайна).