Modificador de acceso "interno" C# cuando se realizan pruebas de unidades

Question

Soy nuevo en las pruebas unitarias y estoy tratando de averiguar si debo comenzar a usar más modificador de acceso 'interno'. Sé que si usamos 'interno' y establecemos la variable de ensamblaje 'InternalsVisibleTo', podemos probar funciones que no queremos declarar públicas del 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 debería usar 'privado'?

Answer 1

clases internas tienen que ser probado y no es un atributo assemby:

using System.Runtime.CompilerServices; 

[assembly:InternalsVisibleTo("MyTests")] 

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

Answer 2

Puede utilizar privado también y puede llamar a métodos privados con reflexión. Si está usando Visual Studio Team Suite, tiene algunas buenas funcionalidades que generarán un proxy para llamar a sus métodos privados por usted. Aquí está un artículo del proyecto de código que muestra cómo se puede hacer el trabajo usted mismo para poner a prueba la unidad de métodos privados y protegidos:

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

En términos de los cuales acceden modificador se debe utilizar, mi regla general es empezar con privada y escalar según sea necesario. De esta forma expondrá la menor cantidad de detalles internos de su clase que realmente se necesitan y ayudará a mantener ocultos los detalles de la implementación, como deberían ser.

Answer 3

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 4

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

Habiendo dicho eso, creo que es razonable hacer que los métodos naturistas sean internos para propósitos de prueba a veces. Prefiero eso al uso de la reflexión, que es refactorizado, antipático.

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 se está utilizando la clase dentro del mismo proyecto, es obvio (ahora y en el futuro) que no se debe realmente use este método, solo está ahí para fines de prueba. Esto es un poco hacky, y no es algo que hago yo mismo, pero al menos vale la pena considerarlo.