Modificador de acceso “interno” de C#al realizar pruebas unitarias

.net unit-testing

Question

Soy nuevo en las pruebas unitarias y estoy tratando de averiguar si debo comenzar a usar más del modificador de acceso "interno". 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 ustedes decirme una razón por la que no debería hacer esto? ¿Cuándo debo usar ''privado''?

Answer 1

Las clases internas necesitan ser probadas y hay un atributo de conjunto:

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("MyTests")]

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

Answer 2

Si desea probar métodos privados, eche un vistazo a PrivateObject y PrivateType en el espacio de nombres Microsoft.VisualStudio.TestTools.UnitTesting . Ofrecen envoltorios fáciles de usar alrededor del código de reflexión necesario.

Docs: PrivateType , PrivateObject

Answer 3

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

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

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

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

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

Entonces, cuando usa la clase dentro del mismo proyecto, es obvio (ahora y en el futuro) que realmente no debería usar este método, solo está ahí para propósitos de prueba. Esto es un poco intrincado, y no es algo que yo haga, pero al menos vale la pena considerarlo.

Answer 4

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

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

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