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

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

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

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


person Aquinas    schedule 08.02.2010    source источник
comment
в зависимости от того, какой язык вы используете, вы можете установить видимость классов ваших библиотек и получить от них некоторые из ваших тестов. Предполагая, что вы использовали защищенный файл .   -  person Liz Albin    schedule 09.02.2010
comment
Основываясь на вашем упоминании NUnit и MSTest, я предположил в своем ответе, что вы используете язык на основе .net, если это неверно, вам было бы полезно сообщить нам об этом =)   -  person Rob    schedule 09.02.2010
comment
Сочетание .NET C# 3.5 (для тестов) и 2.0 (для кода уровня), последнее благодаря отложенному обновлению серверов stage/uat/prod.   -  person Aquinas    schedule 09.02.2010


Ответы (1)


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

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

person Rob    schedule 08.02.2010
comment
Спасибо, это сработало. Пока я использую его экономно, он хорошо согласуется с моей совестью кода. Единственная неприятность заключается в том, что все мои сборки подписаны, и для этого требуется, чтобы моя тестовая сборка была подписана, чтобы использовать вышеуказанный атрибут. - person Aquinas; 09.02.2010