C # «внутренний» модификатор доступа при выполнении модульного тестирования

Я новичок в модульном тестировании и пытаюсь понять, стоит ли мне начинать использовать больше «внутреннего» модификатора доступа. Я знаю, что если мы используем 'internal' и устанавливаем переменную сборки 'InternalsVisibleTo', мы можем тестировать функции, которые не хотим объявлять общедоступными из проекта тестирования. Это заставляет меня думать, что я должен всегда использовать «внутренний», потому что, по крайней мере, у каждого проекта (должен?) Есть свой собственный проект тестирования. Ребята, вы можете сказать мне причину, почему я не должен этого делать? Когда я должен использовать «частный»?

Внутренние классы должны быть проверены и есть атрибут сборки:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

Добавьте это в файл информации о проекте, например Properties\AssemblyInfo.cs.

Если вы хотите проверить личные методы, посмотреть на PrivateObjectи PrivateTypeв Microsoft.VisualStudio.TestTools.UnitTestingпространстве имен. Они предлагают простые в использовании обертки вокруг необходимого кода отражения.

Документы: PrivateType , PrivateObject

Для VS2017 и 2019 вы можете найти их, загрузив nuget MSTest.TestFramework

Добавив ответ Эрика, вы также можете настроить это в csprojфайле:

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>MyTests</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

Или, если у вас есть один тестовый проект на тестируемый проект, вы можете сделать что-то вроде этого в вашем Directory.Build.propsфайле:

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>$(MSBuildProjectName).Test</_Parameter1>
    </AssemblyAttribute>
</ItemGroup>

См .: https://stackoverflow.com/a/49978185/1678053
Пример: https://github.com/gldraphael/evlog/blob/master/Directory.Build.props#L5-L12.

Продолжайте использовать приват по умолчанию. Если член не должен быть представлен вне этого типа, он не должен быть представлен вне этого типа, даже внутри одного и того же проекта. Это делает вещи более безопасными и аккуратными - когда вы используете объект, становится понятнее, какие методы вы должны использовать.

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

Одна вещь, которую следует учитывать, может быть суффиксом «ForTest»:

internal void DoThisForTest(string name)
{
    DoThis(name);
}

private void DoThis(string name)
{
    // Real implementation
}

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

Вы также можете использовать private и вызывать private методы с отражением. Если вы используете Visual Studio Team Suite, у него есть приятная функциональность, которая генерирует прокси для вызова ваших личных методов. Вот статья проекта кода, которая демонстрирует, как вы можете выполнить работу самостоятельно для тестирования отдельных и защищенных методов:

http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx

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

Я использую Dotnet 3.1.101и .csprojдополнения, которые работали для меня были:

<PropertyGroup>
  <!-- Explicitly generate Assembly Info -->
  <GenerateAssemblyInfo>true</GenerateAssemblyInfo>
</PropertyGroup>

<ItemGroup>
  <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleToAttribute">
  <_Parameter1>MyProject.Tests</_Parameter1>
  </AssemblyAttribute>
</ItemGroup>

Надеюсь, это поможет кому-то там!