Modificador de acceso “interno” C # cuando se realizan pruebas unitarias

Soy nuevo en 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’?

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 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.

Documentos: PrivateType , PrivateObject

También puede usar privado 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í 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:

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 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.

Sigue usando privado 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 naturalmente privados 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 está utilizando 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 fines de prueba. Esto es un poco hacky, y no es algo que hago yo mismo, pero al menos vale la pena considerarlo.