Aislamiento del código sometido a prueba con Microsoft Fakes

El aislamiento de código es una estrategia de prueba que a menudo se implementa con herramientas como Microsoft Fakes, donde el código que está probando está separado del resto de la aplicación. Esta separación se logra sustituyendo partes de la aplicación que interactúan con el código que se está probando por stubs o capas de compatibilidad. Estos son pequeños fragmentos de código controlados por las pruebas, que simulan el comportamiento de las partes reales que reemplazan.

La ventaja de este enfoque es que permite centrarse en probar la funcionalidad específica del código de forma aislada. Si se produce un error en una prueba, sabe que la causa está dentro del código aislado y no en ningún otro lugar. Además, el uso de stubs y shims, proporcionados por Microsoft Fakes, le permite probar su código incluso si otras partes de la aplicación todavía no funcionan.

Requisitos

Nota:

La generación de perfiles con Visual Studio no está disponible para las pruebas que usan Microsoft Fakes.

El rol de Microsoft Fakes en aislamiento de código

Microsoft Fakes desempeña un papel clave en el aislamiento del código mediante dos mecanismos: stubs y shims.

  • Stubs: se utilizan para reemplazar una clase por un pequeño sustituto que implementa la misma interfaz. Esto requiere que la aplicación se diseñe de forma que cada componente solo dependa de interfaces, no de otros componentes.

  • Shims: Estos se usan para modificar en tiempo de ejecución el código compilado de su aplicación. En lugar de llamar a un método concreto, la aplicación ejecuta el código shim que proporciona la prueba. Los Shims pueden reemplazar llamadas a ensamblados que no se pueden modificar, como los ensamblados de .NET.

Normalmente, los stubs se usan en las llamadas dentro de su solución de Visual Studio, y los shims para las llamadas a otros ensamblados referenciados. Esto se debe a que, en tu solución, es una buena práctica desacoplar los componentes definiendo interfaces según lo requieran las simulaciones. Sin embargo, los ensamblajes externos a menudo no incluyen definiciones de interfaz independientes, por lo que se utilizan shims en su lugar.

Diagrama que muestra Fakes reemplazando otros componentes.

Recomendaciones sobre cuándo usar stubs

Normalmente, los stubs se usan para las llamadas dentro de tu solución de Visual Studio, ya que es una buena práctica desacoplar los componentes definiendo interfaces, tal como requiere el uso de stubs. Sin embargo, los ensamblados externos, como System.dll, por lo general no se proporcionan con definiciones de interfaz independientes, por lo que en estos casos se utilizan shims en su lugar.

El uso de stubs implica diseñar su aplicación de modo que los distintos componentes no dependan entre sí, sino únicamente de las definiciones de interfaz. Este desacoplamiento hace que la aplicación sea más sólida y flexible, y permite conectar el componente sometido a prueba a implementaciones simuladas de las interfaces para realizar pruebas.

En la práctica, puede generar tipos de código auxiliar a partir de las definiciones de interfaz en Visual Studio y, a continuación, reemplazar el componente real por el código auxiliar de la prueba.

Recomendaciones sobre cuándo usar shims

Aunque los stubs se usan para las llamadas dentro de su solución de Visual Studio, los shims se usan normalmente para las llamadas a otros ensamblados referenciados. Esto se debe a que los ensamblados externos, como System.dll, normalmente no suelen proporcionarse con definiciones de interfaz independientes, por lo que deben utilizarse shims en su lugar.

Sin embargo, hay algunos factores que se deben tener en cuenta al utilizar capas de compatibilidad:

Rendimiento: las correcciones de compatibilidad se ejecutan más lentamente porque vuelven a escribir el código en tiempo de ejecución. Los stubs no tienen esta sobrecarga de rendimiento y son tan rápidos como pueden llegar a serlo los métodos virtuales.

Métodos estáticos, tipos sellados: solo se pueden usar stubs para implementar interfaces. Por lo tanto, los tipos de stubs no se pueden usar para métodos estáticos, métodos no virtuales, métodos virtuales sellados, métodos en tipos sellados, etc.

Tipos internos: tanto los stubs como los shims se pueden usar con tipos internos que se hacen accesibles mediante el atributo de ensamblado InternalsVisibleToAttribute.

Métodos privados: Los shims pueden reemplazar las llamadas a métodos privados si todos los tipos de la firma del método son visibles. Los stubs solo pueden sustituir métodos visibles.

Interfaces y métodos abstractos: los stubs proporcionan implementaciones de interfaces y métodos abstractos que pueden utilizarse en las pruebas. Los shims no pueden instrumentar interfaces ni métodos abstractos, ya que no tienen cuerpos de método.

Transición de Microsoft Fakes en .NET Framework a proyectos de SDK-Style

Realizar la transición de los proyectos de prueba de .NET Framework que usan Microsoft Fakes a .NET Framework de estilo SDK, .NET Core o proyectos de .NET 5+.

Necesitará cambios mínimos en la configuración de .NET Framework para que Microsoft Fakes realice la transición a .NET Core o .NET 5.0. Los casos que tendría que tener en cuenta son:

  • Si usa una plantilla de proyecto personalizada, debe asegurarse de que siga el estilo del SDK y se compile para un framework de destino compatible.

  • Algunos tipos existen en ensamblados diferentes en .NET Framework y .NET Core/.NET 5.0 (por ejemplo, System.DateTime existe en System/mscorlib en .NET Framework y en System.Runtime en .NET Core y .NET 5.0), y en estos escenarios debe cambiar el ensamblado que se está falsificando.

  • Si tiene una referencia de ensamblado a un ensamblado de Fakes y al proyecto de pruebas, es posible que vea una advertencia de compilación sobre una referencia que no se encuentra, similar a esta:

    (ResolveAssemblyReferences target) ->
warning MSB3245: Could not resolve this reference. Could not locate the assembly "AssemblyName.Fakes". Check to make sure the assembly exists on disk.
If this reference is required by your code, you may get compilation errors.

    Esta advertencia se debe a los cambios necesarios en la generación de Fakes y puede ignorarse. Se puede evitar quitando la referencia de ensamblado del archivo del proyecto, ya que ahora se agregan implícitamente durante la compilación.

Ejecución de pruebas de Microsoft Fakes

Siempre que los ensamblados Microsoft Fakes estén presentes en el directorio FakesAssemblies configurado (el valor predeterminado es $(ProjectDir)FakesAssemblies), puede ejecutar pruebas con la tarea vstest.

Las pruebas distribuidas con la tarea vstest en proyectos de .NET Core y .NET 5+ que usan Microsoft Fakes requieren Visual Studio 2019 Update 9 Preview 20201020-06 y versiones posteriores.

Compatibilidad y soporte de Microsoft Fakes en diferentes versiones de .NET y Visual Studio

Microsoft Fakes en proyectos antiguos dirigidos a .NET Framework (estilo no SDK).

  • La generación de ensamblados Fakes de Microsoft es compatible con Visual Studio Enterprise 2015 y versiones posteriores.
  • Las pruebas de Microsoft Fakes se pueden ejecutar con todos los paquetes NuGet de Microsoft.TestPlatform disponibles.
  • La cobertura de código es compatible con proyectos de prueba que usan Microsoft Fakes en Visual Studio Enterprise 2015 y versiones posteriores.

Microsoft Fakes en proyectos de .NET Framework con estilo SDK, .NET Core y .NET 5.0 o versiones posteriores

  • La generación de ensamblados de Microsoft Fakes se presentó en versión preliminar en Visual Studio Enterprise 2019 Update 6 y está habilitada de forma predeterminada en Update 8.
  • Las pruebas de Microsoft Fakes para proyectos dirigidos a .NET Framework pueden ejecutarse con todos los paquetes NuGet disponibles de Microsoft.TestPlatform.
  • Las pruebas de Microsoft Fakes para proyectos dirigidos a .NET Core y .NET 5.0 o versiones posteriores pueden ejecutarse con los paquetes NuGet de Microsoft.TestPlatform con versiones 16.9.0-preview-20210106-01 y superiores.
  • La cobertura de código es compatible con proyectos de prueba destinados a .NET Framework mediante Microsoft Fakes en Visual Studio Enterprise versión 2015 y posteriores.
  • La compatibilidad con la cobertura de código para proyectos de prueba dirigidos a .NET Core y .NET 5.0 o versiones posteriores que usan Microsoft Fakes está disponible en Visual Studio 2019 Update 9 y versiones posteriores.

Contenido relacionado

  • Last updated on