c# - pruebas - Unidad que prueba los métodos internos en la biblioteca VS2017.Net Standard

pruebas unitarias c#

Question

Actualmente estoy jugando con el último Visual Release 2017 Release Candidate creando una biblioteca .Net Standard 1.6. Estoy usando xUnit para probar mi código y me preguntaba si aún puede probar métodos internos en VS2017.

Recuerdo que podría tener toda una línea clase AssemblyInfo.cs en VS2015 que permitiría que proyectos específicos vean métodos internos

[assembly:InternalsVisibleTo("MyTests")]

Como no hay una clase AssemblyInfo.cs en los proyectos VS2017 .Net Standard, me preguntaba si aún puede probar los métodos internos de la unidad.

Answer 1

De acuerdo con los documentos .NET para InternalsVisibleToAttribute :

El atributo se aplica a nivel de ensamblaje. Esto significa que se puede incluir al comienzo de un archivo de código fuente, o se puede incluir en el archivo AssemblyInfo en un proyecto de Visual Studio.

En otras palabras, simplemente puede colocarlo en su propio archivo .cs nombrado arbitrariamente, y debería funcionar bien:

// some .cs file included in your project
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("MyTests")]

Answer 2

El atributo "InternalsVisibleTo" es clave para cualquier tipo de prueba de "caja blanca" (el término de la década, supongo) para .Net. Se puede colocar en cualquier archivo C # con el atributo "ensamblado" en el frente. Tenga en cuenta que los MS DOC dicen que el nombre del ensamblado debe ser calificado por el token de clave pública, si está firmado. A veces eso no funciona y uno debe usar la clave pública completa en su lugar. El acceso a componentes internos es clave para probar sistemas concurrentes y en muchas otras situaciones. Ver https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054 . En este libro, Meszaros describe una variedad de estilos de codificación que básicamente constituyen un enfoque de "Diseño para prueba" para el desarrollo de programas. Al menos así lo he usado a lo largo de los años.

Answer 3

Otra forma es usar una clase pública ''wrapper'' TestMyFoo dentro del proyecto de destino que tiene métodos públicos e inherentes de la clase que necesita probar (por ejemplo, MyFoo). Estos métodos públicos simplemente llaman a la clase base que desea probar.

No es ''ideal'' ya que terminas enviando un gancho de prueba en tu proyecto de destino. Pero tenga en cuenta que los automóviles modernos y confiables se envían con puertos de diagnóstico y los dispositivos electrónicos modernos y confiables se envían con una conexión JTAG. Pero nadie es tan tonto como para conducir su automóvil usando el puerto de diagnóstico.

Answer 4

Si bien la primera respuesta está perfectamente bien. Si todavía desea hacer esto en el AssemblyInfo original AssemblyInfo siempre puede elegir no generar automáticamente el archivo y agregarlo manualmente.

<PropertyGroup>
   <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

Para más información: https://.com/a/47075759/869033