2015-08-13 3 views
0

Я пишу свой UnitTests в отдельном проекте из моего проекта в тесте. Чтобы иметь возможность тестировать классы/члены Internal, я использую атрибут [InternalsVisibleTo] в моем проекте под тестированием. возникаетЕдиничные тесты, конфигурация сборки и внутренние номера

#if "BUILD_CONFIGURATION" 
[assembly: InternalsVisibleTo("Tests_ProjectUnderTest")] 
#endif 

следующий вопрос:

Какие сборки конфигурации следует использовать для модульных тестов? Internal s не должны быть видны в моем выпущенном коде, поэтому #if RELEASE невозможен. С другой стороны, #if DEBUG действительно не проверяет, что я хочу выпустить. Должны ли у вас отличные UNIT_TEST -конфигурация? Или как вы это сделаете?

+4

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

ответ

0

Я обычно не делаю атрибут [InternalsVisibleTo()] условным, так как внутренние элементы становятся видимыми только для названного узла. Вы можете усилить безопасность этого путем сильного именования сборок, поэтому никто не может «подделать» вашу единицу тестовой сборки. Однако, если вы , что обеспокоены этим, вы, вероятно, должны все равно запутывать свои сборки, иначе обратное проектирование тривиально. Обычно я отношусь к тому, что частное/внутреннее является заявлением о намерениях, а не функцией безопасности, поскольку его всегда можно обойти, используя отражение.

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

Смежные вопросы