Интеграционное тестирование частных классов и методов

Question

Для модульного тестирования вы не должны тестировать частные методы, да, но для интеграционных тестов (с использованием инфраструктуры модульного тестирования, такой как MSTest или NUnit), я бы очень хотел выполнить внутренние вызовы API для URL-адреса теста, чтобы текущий код работает, когда сторонний поставщик API меняет свой бэкэнд.

Учитывая сложность системы (глупые API имеют сотни параметров), я скрыл большую часть ее за интерфейсами и IoC, а вспомогательный класс API полностью встроен в нашу библиотеку уровня данных. Я не хочу менять это, потому что раньше он был общедоступным, и мы нашли странного разработчика, нового для проекта и неопытного в целом, который быстро пошел бы вперед и вызвал API непосредственно из кода сайта. Создание внутреннего класса должно гарантировать, что они хотя бы думают, прежде чем уничтожить точку нашего уровня абстракции.

Я создавал массу кода для отражения внутренних методов, но он работает не слишком хорошо и получает sphagetti-ish. Есть ли способ сделать методы публично видимыми для определенных библиотек? Есть ли способ заставить тестовый libray рассматривать себя как часть библиотеки, содержащей API? Является ли что-нибудь из этой лучшей практики?

Answer 1

Атрибут InternalsVisibleTo является вашим другом здесь =) Если вы поместите его в AssemblyInfo.cs (по крайней мере, это то место, где я обычно его помещаю) и укажите имя (имена) тестовых / других сборок Вы хотите открыть внутренние методы для них, тогда они доступны. Дополнительный бонус (по крайней мере, на мой взгляд) заключается в том, что система / компилятор intellisense в Visual Studio знает об атрибуте и его назначении, и вам будет предоставлен полный intellisense для внутренних методов.

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