Acceso a miembros internos a través de System.Reflection?

StackOverflow https://stackoverflow.com/questions/171332

  •  05-07-2019
  •  | 
  •  

Pregunta

Estoy intentando realizar una prueba de unidad de una clase que tiene muchas funciones internas. Obviamente, estos también necesitan pruebas, pero mi proyecto de Pruebas es independiente, principalmente porque cubre muchos proyectos pequeños relacionados. Lo que tengo hasta ahora es: 

FieldInfo[] _fields = 
    typeof(ButtonedForm.TitleButton).GetFields(
        BindingFlags.NonPublic | BindingFlags.Instance | 
        BindingFlags.DeclaredOnly);
Console.WriteLine("{0} fields:", _fields.Length);
foreach (FieldInfo fi in _fields)
{
    Console.WriteLine(fi.Name);
}

Esto escupe muy bien a todos los miembros privados, pero aún no muestra elementos internos. Sé que esto es posible, porque cuando estaba jugando con las pruebas autogeneradas que Visual Studio puede producir, me preguntó qué tenía que ver con mostrar las partes internas del proyecto de Prueba. Bueno, ahora estoy usando NUnit y realmente me gusta, pero ¿cómo puedo lograr lo mismo con él?

¿Fue útil?

Solución

Sería más apropiado usar el InternalsVisibleTo para otorgar acceso a los miembros internos del ensamblaje a su ensamblaje de prueba de unidad.

Aquí hay un enlace con información adicional útil y un recorrido:

Para responder realmente a su pregunta ... Internas y protegidas no se reconocen en la API de .NET Reflection. Aquí hay una cita de MSDN :

  

Las palabras clave C # protegidas e internas no tienen significado en IL y no se utilizan en las API de Reflection. Los términos correspondientes en IL son Familia y Asamblea. Para identificar un método interno utilizando Reflection, use IsAssembly propiedad. Para identificar un método interno protegido, use IsFamilyOrAssembly .

Otros consejos

Agregar el InternalsVisibleTo atributo de nivel de conjunto a su proyecto principal, con el nombre de la Asamblea del proyecto de prueba debe hacer que los miembros internos estén visibles.

Por ejemplo, agregue lo siguiente a su ensamblaje fuera de cualquier clase: 

[assembly: InternalsVisibleTo("AssemblyB")]

O para una orientación más específica: 

[assembly:InternalsVisibleTo("AssemblyB, PublicKey=32ab4ba45e0a69a1")]

Tenga en cuenta que si el ensamblaje de la aplicación tiene un nombre seguro, también será necesario que su ensamblaje de prueba tenga un nombre seguro.

Creo que debes preguntar si deberías escribir pruebas unitarias para métodos privados. Si escribe pruebas de unidad para sus métodos públicos, con una cobertura de código 'razonable', ¿no está probando ya algún método privado que deba llamarse como resultado?

Vincular pruebas a métodos privados hará que las pruebas sean más frágiles. Debería poder cambiar la implementación de cualquier método privado sin interrumpir ninguna prueba.

Refs:

http://weblogs.asp.net/tgraham/ archive / 2003/12/31 / 46984.aspx http://richardsbraindump.blogspot.com/2008 /08/should-i-unit-test-private-methods.html http://junit.sourceforge.net/doc/faq/faq.htm#tests_11 http://geekswithblogs.net/geekusconlivus/archive/2006/07/13 /85088.aspx

Su código solo muestra campos, por lo que espero que no muestre miembros internos, ya que los campos siempre deben ser IMO privados. (Con la posible excepción de las constantes).

¿ButtonedForm.TitleButton tiene campos no privados? Si está tratando de encontrar métodos internos, obviamente necesita llamar a GetMethods (o GetMembers ) para obtenerlos.

Como han sugerido otros, InternalsVisibleTo es muy útil para las pruebas (¡y casi solo para las pruebas!). En cuanto a si debe probar métodos internos, ciertamente me parece útil poder hacerlo. No considero que las pruebas unitarias sean exclusivamente pruebas de caja negra. A menudo, cuando sabe que la funcionalidad pública se implementa utilizando unos pocos métodos internos conectados de una manera sencilla, es más fácil realizar pruebas exhaustivas de cada uno de los métodos internos y algunos de los cuales " seudo-integración " Pruebas sobre el método público.

Una justificación para usar InternalsVisible está bajo mis circunstancias. Compramos el código fuente a un control gráfico. Hemos encontrado dónde necesitamos hacer algunas modificaciones a ese control de origen y compilar nuestra propia versión. Ahora, para garantizar que no hayamos hecho nada, hay algunas pruebas unitarias que necesito escribir y que necesitan acceso a algunos campos internos.

Este es un caso perfecto en el que InternalsVisible tiene sentido.

Me preguntaba, sin embargo, ¿qué haces si no tienes acceso a la fuente? ¿Cómo podrías llegar a un campo interno? .Net Reflector puede ver ese código, pero supongo que solo está mirando el IL.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top