Modificador de acceso "interno" de C # al realizar pruebas unitarias

Soy nuevo en pruebas unitarias y estoy tratando de averiguar si debo comenzar a usar más modificadores de acceso 'internos'. Sé que si usamos 'interno' y configuramos la variable de ensamblaje 'InternalsVisibleTo', podemos probar funciones que no queremos declarar públicas desde el proyecto de prueba. Esto me hace pensar que siempre debería usar 'interno' porque al menos cada proyecto (¿debería?) Tiene su propio proyecto de prueba. ¿Pueden decirme una razón por la que no debería hacer esto? ¿Cuándo debo usar 'privado'?

Las clases internas deben probarse y hay un atributo de ensamblaje:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

Agregue esto al archivo de información del proyecto, por ejemplo Properties\AssemblyInfo.cs.

Si desea probar métodos privados, eche un vistazo a PrivateObjecty PrivateTypeen el Microsoft.VisualStudio.TestTools.UnitTestingespacio de nombres. Ofrecen envoltorios fáciles de usar alrededor del código de reflexión necesario.

Documentos: PrivateType , PrivateObject

Para VS2017 y 2019, puede encontrarlos descargando el MSTest.TestFramework nuget

Agregando a la respuesta de Eric, también puede configurar esto en el csprojarchivo:

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

O si tiene un proyecto de prueba por proyecto para probar, puede hacer algo como esto en su Directory.Build.propsarchivo:

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

Ver: https://stackoverflow.com/a/49978185/1678053
Ejemplo: https://github.com/gldraphael/evlog/blob/master/Directory.Build.props#L5-L12

Sigue usando privado por defecto. Si un miembro no debería exponerse más allá de ese tipo, no debería exponerse más allá de ese tipo, incluso dentro del mismo proyecto. Esto mantiene las cosas más seguras y ordenadas: cuando usa el objeto, queda más claro qué métodos debe usar.

Dicho esto, a veces creo que es razonable hacer que los métodos naturalmente privados sean internos para fines de prueba. Prefiero eso a usar la reflexión, que es refactorizadora-hostil.

Una cosa a considerar podría ser un sufijo "ForTest":

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

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

Luego, cuando usa la clase dentro del mismo proyecto, es obvio (ahora y en el futuro) que realmente no debería estar usando este método, solo está allí para fines de prueba. Esto es un poco hacky, y no es algo que yo haga, pero al menos vale la pena considerarlo.

También puede usar privado y puede llamar a métodos privados con reflexión. Si está utilizando Visual Studio Team Suite, tiene una buena funcionalidad que generará un proxy para llamar a sus métodos privados por usted. Aquí hay un artículo de proyecto de código que muestra cómo puede hacer el trabajo usted mismo para probar métodos privados y protegidos:

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

En términos de qué modificador de acceso debe usar, mi regla general es comenzar con privado y escalar según sea necesario. De esa manera, expondrá los detalles internos de su clase tan pocos como sean realmente necesarios y ayudará a mantener ocultos los detalles de implementación, como deberían ser.

Estoy usando Dotnet 3.1.101y las .csprojadiciones que funcionaron para mí fueron:

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

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

Espero que esto ayude a alguien por ahí!