Сборки .NET, охватывающие несколько файлов и модульное тестирование

Question

Может кто-нибудь указать мне некоторую информацию о сборках .NET, охватывающих несколько файлов?

Я нашел это замечание в MSDN ( здесь ):

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

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

Answer 1

Вы можете дружить двумя сборками вместе. Тогда можно увидеть «внутреннее» в другом. Все еще не могу видеть личное.

MSDN - http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx

Answer 2

Если вы хотите проверить внутренние методы, тогда атрибут InternalsVisibleTo является для вас. Фактически, тестирование внутренних классов / методов - фактически единственное, для чего я когда-либо использовал это.

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

Answer 3

Я бы сказал, выбрать между двумя вариантами ниже

• Если внутренние классы действительно тривиальны и являются частными для родительской сборки, пропустите тесты. Тесты для открытых классов, которые осуществляют эти внутренние классы, должны их охватить.
• Если внутренний класс значительный и действительно нуждается в собственных тестах. Разделите ответственность контроля доступа на другой класс. Сделайте внутренние классы общедоступными и напишите тесты, как обычно. Сделайте известным соглашением команды, что внутренние классы не создаются напрямую вне родительской сборки, или используйте другой класс в качестве единой точки доступа к «внутренним классам».

ИМХО Только если вы действительно беспокоитесь о том, чтобы не раскрывать внутренние типы + обязательно должны их проверить, перейдите к Варианту 2. Option1 позволяет вам изменить внутреннюю реализацию / классы в любое время, не нарушая никаких тестов. Не используйте неясные способы разделения сборок между несколькими физическими файлами для тестирования.

Answer 4

Тестирование внутренних классов должно происходить через тестирование ваших открытых методов.