Модульное тестирование C# с аксессорами - Конструкторы не работают

Question

Я должен написать модульный тест для моего приложения, но у меня есть проблема. Я использую C# и.NET 4. В своих тестах я не могу получить доступ к закрытым свойствам и методам класса, поэтому я использую автоматически генерируемые аксессоры для каждого класса в модульных тестах, но...

Мои конструкторы для классов Accessor не принимают их аргументы. Пример:

class SearchControl(bool isLogged, MainWindow mainWindow);
class MainWindow();

Для создания объекта типа SearchControl вам нужно передать объект mainWindow. Поэтому, если я сделал это с не классами Accessor, я не могу получить доступ к закрытым методам и свойствам и не могу их протестировать.

MainWindow mainWindow = new MainWindow();
SearchControl serchControl = new SearchControl(false, mainWindow);

Я должен использовать предложения Accessor, но когда я делаю это, мой код подчеркивается красным, и Visual Studio говорит, что аргументы не могут быть приняты. Почему, когда я передаю аргументы одного типа. Если я снова передам объект MainClass в объект SearchControl_Accessor, я не смогу получить доступ к свойствам в MainClass. Так что код с аксессорами выглядит так:

MainWindow_Accessor mainWindow = new MainWindiow_Accessor();
SearchControl_Accessor searchControl = new SearchControl_Accessor(false, mainWindow);

Любой, кто знает, что не так и что я должен сделать, чтобы это исправить. Спасибо:)

Answer 1

Если вам необходимо выполнить модульное тестирование закрытых методов, возможно, начинать разработку классов плохо? Мое (несколько слабое, я признаю) понимание состоит в том, что "внешний мир" не должен заботиться о частных методах объекта - только в том случае, если он делает то, что написано на коробке справа. Частные методы не являются частью "контракта" - их реализация, типы возвращаемых данных и т. Д. Могут меняться, публичный API имеет значение.

В каком случае публичные методы вашего объекта могут пройти тесты, в то время как частные методы не сработали? Если это возможно, то либо:

• публичные методы не проверены должным образом, или
• частные методы не имеют значения - они не влияют на поведение объекта и, следовательно, не нуждаются в проверке.

Или это невозможно, но вы хотите протестировать закрытые методы, чтобы определить, какой из них приводит к неожиданному поведению какого-либо открытого метода?

Если это так, это может означать, что:

• эти публичные методы должны быть меньше (делать меньше вещей, и благодаря этому вы не будете полностью сбиты с толку тем, какой частный метод может быть виновен), плюс
• хорошей идеей было бы генерировать конкретные исключения, когда частные методы, которые они используют, ведут себя неправильно. Затем вы тестируете публичные методы для этих исключений.

Answer 2

Обычно вы не можете получить доступ к закрытым свойствам, методам и полям объекта. Если вам действительно нужно получить к нему доступ, вы можете рассмотреть возможность сделать их internal (вместо private). Если ваши тесты находятся в другой сборке, проверьте атрибут InternalsVisibleTo. Этот атрибут, при правильном применении к сборке с кодом, который вы хотите проверить, позволяет вашей сборке с тестами получать доступ к вашим методам, полям и свойствам, которые вы отметили internal,

Я надеюсь, что я правильно понял ваш вопрос, так как вы используете неясную терминологию (классы доступа). Пожалуйста, объясните или спросите, хотите ли вы узнать больше.