c# - working - internalsvisibleto.net core




Является ли плохой практикой использование InternalsVisibleTo для модульного тестового кода? (4)

Лично я думаю, что все в порядке. Я никогда не соглашался с догмой «только проверять общественные методы». Я думаю, что хорошо также иметь тестирование черного ящика, но тестирование белого ящика может позволить вам протестировать больше сценариев с более простыми тестами, особенно если ваш API достаточно «коренастый», а общественные методы на самом деле выполняют довольно много работы.

Аналогично, в хорошо инкапсулированном проекте вы можете иметь несколько внутренних типов только с внутренними методами. Теперь, вероятно, это будет иметь общественное влияние, поэтому вы можете сделать все тестирование только через общедоступные типы, но тогда вам, возможно, придется пройти через множество обручей, чтобы на самом деле проверить что-то, что действительно просто проверить с помощью InternalsVisibleTo .

Пример кода в AssemblyInfo.cs :

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo
                          ("Test.Company.Department.Core")]

Это плохая практика?


Нет, когда используется правильно, потому что в некоторых сценариях это необходимо. Например, у вас есть модульный тест A который должен проверить открытый член сборки B который использует некоторый внутренний тип, также определенный в сборке B Тестирование модуля требует этого типа, поэтому вы должны использовать InternalsVisibleTo .

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


Я думаю, что это вполне разумно сделать.

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


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

Однако тестирование через публичный API предпочтительнее, поскольку упрощает рефакторинг межсайтовых API. Используйте InternalsVisibleTo с осторожностью и только при необходимости, например, размер API значителен.





.net