Внутренние методы тестирования модулей в VS2017. Стандартная библиотека стандарта.

В настоящее время я играю с последним кандидатом на выпуск Visual Studio 2017, создав библиотеку .Net Standard 1.6. Я использую xUnit для unit test моего кода и задавался вопросом, можете ли вы все еще тестировать внутренние методы в VS2017.

Я помню, что вы могли бы создать класс AssemblyInfo.cs в VS2015, который позволил бы указанным проектам видеть внутренние методы

[assembly:InternalsVisibleTo("MyTests")]

Как нет класса AssemblyInfo.cs в VS2017. Стандартные проекты. Мне было интересно, можете ли вы еще unit test внутренние методы?

Ответ 1

В соответствии с .NET docs для InternalsVisibleToAttribute:

Атрибут применяется на уровне сборки. Это означает, что он может быть включен в начале файла исходного кода или может быть включен в файл AssemblyInfo в проекте Visual Studio.

Другими словами, вы можете просто поместить его в свой собственный файл с произвольным именем .cs, и он должен работать нормально:

// some .cs file included in your project
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("MyTests")]

Ответ 2

Атрибут "InternalsVisibleTo" является ключом к любому типу "белого ящика" (срок десятилетия, я думаю) для тестирования .Net. Он может быть помещен в любой файл С# с атрибутом "assembly" на передней панели. Обратите внимание, что MS DOC говорят, что имя сборки должно быть квалифицировано маркером открытого ключа, если оно подписано. Иногда это не работает, и нужно использовать полный открытый ключ в нем. Доступ к внутренним элементам является ключом к тестированию параллельных систем и во многих других ситуациях. См. https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054. В этой книге Meszaros описывает различные стили кодирования, которые в основном составляют подход "Дизайн для теста" к разработке программ. По крайней мере, так, как я использовал его на протяжении многих лет.