В настоящее время я работаю с последней версией кандидата на выпуск Visual Studio 2017, создавая библиотеку .Net Standard 1.6. Я использую xUnit для модульного тестирования моего кода, и мне было интересно, можете ли вы по-прежнему тестировать внутренние методы в VS2017.
Я помню, что вы могли бы все строки класса AssemblyInfo.cs в VS2015, которые позволили бы указанным проектам видеть внутренние методы
[assembly:InternalsVisibleTo("MyTests")]Поскольку в проектах VS2017 .Net Standard нет класса AssemblyInfo.cs, мне было интересно, можно ли по-прежнему использовать внутренние методы для модульного тестирования?
c#
unit-testing
visual-studio-2017
.net-standard
Фил Мюррей
источник
источник
namespaceблока, и он должен скомпилироваться. В этом не должно быть ничего волшебногоAssemblyInfo.cs. Разве это не работает? Конечно, вам нужно добавить правильноеusingпредложение или использовать полностью определенный атрибут[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("Something")].InternalsVisibleToочень важно - например, здесь - stackoverflow.com/a/17574183/43453Ответы:
Согласно документам .NET для
InternalsVisibleToAttribute:Другими словами, вы можете просто поместить его в свой произвольно названный файл .cs, и он должен работать нормально:
источник
AssemblyInfo.csфайл, как описано здесь . В противном случае все атрибуты, такие как «description», «copyright» и другие, хранятся в файле .csproj.Как описано здесь:
https://blog.sanderaernouts.com/make-internals-visible-with-new-csproj-format
Можно добавить внутренний видимый атрибут в файл проекта, добавив еще одну ItemGroup:
или даже:
Мне нравится это решение, потому что файл проекта, кажется, является правильным местом для определения таких проблем.
источник
Пока с первым ответом все отлично. Если вы чувствуете, что все еще хотите сделать это в оригинале,
AssemblyInfoвы всегда можете не создавать файл автоматически и добавлять его вручную.Для получения дополнительной информации: https://stackoverflow.com/a/47075759/869033
источник
Атрибут «InternalsVisibleTo» является ключом к любому виду «белого ящика» (я полагаю, термин десятилетия) для тестирования .Net. Его можно поместить в любой файл C # с атрибутом «Assembly» на передней панели. Обратите внимание, что MS DOC говорят, что имя сборки должно быть квалифицировано токеном открытого ключа, если он подписан. Иногда это не работает, и нужно использовать полный открытый ключ вместо него. Доступ к внутренним компонентам является ключом к тестированию параллельных систем и во многих других ситуациях. См. Https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054 . В этой книге Месарош описывает множество стилей кодирования, которые в основном составляют подход «Дизайн для теста» к разработке программ. По крайней мере, так я и использовал на протяжении многих лет.
ДОБАВЛЕНО: Извините, я не был здесь некоторое время. Один из подходов Месарош назвал «подходом подкласса тестирования». Опять же, нужно использовать «internalsvisableto» для доступа к внутренним компонентам базового класса. Это отличное решение, но оно не работает для закрытых классов. Когда я преподаю «Дизайн для тестирования», я предполагаю, что это одна из вещей, которые необходимо «предварительно спроектировать» в базовые классы, чтобы обеспечить тестируемость. Это должно стать почти культурной вещью. Создайте «базовый» базовый класс, который будет закрыт. Назовите это UnsealedBaseClass или что-то однообразно узнаваемое. Это класс, который нужно разделить на подклассы для тестирования. Это также подкласс для создания производственного герметичного класса, который часто отличается только конструкторами, которые он выставляет. Я работаю в атомной отрасли, и требования к испытаниям принимаются ОЧЕНЬ серьезно. Итак, я должен думать об этом все время. Кстати, оставить тестирование в производственном коде не является проблемой в нашей области, поскольку они являются «внутренними» в реализации .Net. Последствия НЕ тестирования чего-либо могут быть довольно глубокими.
источник
Другой способ - использовать открытый класс TestMyFoo «обертки» внутри целевого проекта, который имеет открытые методы и наследует от класса, который нужно протестировать (например, MyFoo). Эти открытые методы просто обращаются к базовому классу, который вы хотите протестировать.
Это не «идеально», так как в конечном итоге вы отправляете тестовый хук в свой целевой проект. Но рассмотрим современные надежные автомобили с диагностическими портами и современную надежную электронику с разъемом JTAG. Но никто не настолько глуп, чтобы водить машину, используя диагностический порт.
источник