Probar aplicaciones de EF Core

Las pruebas son una preocupación importante para casi todos los tipos de aplicación: permite asegurarse de que la aplicación funciona correctamente y hace que se sepa al instante si su comportamiento se devuelve en el futuro. Dado que las pruebas pueden afectar a la arquitectura del código, se recomienda planear las pruebas tempranamente y garantizar una buena cobertura a medida que evoluciona la aplicación. En esta sección introductoria se proporciona información general rápida de varias estrategias de prueba para aplicaciones que usan EF Core.

Implicación de la base de datos (o no)

Al escribir pruebas para la aplicación de EF Core, una decisión básica que debe tomar es si las pruebas implicarán el sistema de base de datos de producción (igual que la aplicación) o si las pruebas se ejecutarán en un doble de prueba, lo que reemplaza al sistema de base de datos de producción. Dos ejemplos destacados de dobles de prueba en el contexto de EF Core son el modo en memoria de SQLite y el proveedor en memoria.

Para obtener una comparación y un análisis detallados de los distintos enfoques, consulte Elección de una estrategia de prueba. A continuación se muestra un breve resumen de punto a punto para ayudarle a ponerse al día con las distintas opciones:

• Los desarrolladores suelen evitar pruebas en su sistema de base de datos de producción porque creen que esto es difícil o lento. Esto no siempre es cierto en nuestra experiencia y se recomienda ofrecer a este enfoque una oportunidad: Las pruebas en el sistema de base de datos de producción proporcionan técnicas para hacerlo de forma confiable y eficaz. La escritura de al menos algunas pruebas en la base de datos suele ser necesaria en cualquier caso, para asegurarse de que la aplicación funciona realmente en la base de datos de producción, y las pruebas que no implican la base de datos pueden limitarse en lo que le permiten probar (consulte a continuación).
• El proveedor en memoria no se comportará como tu base de datos real en muchos aspectos importantes. Algunas características no se pueden probar con ella (por ejemplo, transacciones, SQL sin procesar)., mientras que otras características pueden comportarse de forma diferente a la base de datos de producción (por ejemplo, distinción entre mayúsculas y minúsculas en las consultas). Aunque el uso en memoria puede funcionar para escenarios de consulta sencillos y restringidos, está muy limitado y su uso se desaconseja.
  • La simulación de DbSet para consultas es compleja y difícil, y sufre las mismas desventajas que el enfoque en memoria; desaconsejamos esto también.
• El modo en memoria de SQLite ofrece una mejor compatibilidad con las bases de datos relacionales de producción, ya que SQLite es una base de datos relacional completa. Sin embargo, todavía habrá algunas discrepancias importantes entre SQLite y la base de datos de producción, y algunas características no se pueden probar en absoluto (por ejemplo, métodos específicos del proveedor en EF. Funciones).
• Para una estrategia de prueba que te permite usar un doble de prueba confiable para toda la funcionalidad de tu sistema de base de datos de producción, es posible introducir una capa de repositorio en tu aplicación. Esto le permite excluir EF Core por completo de las pruebas y simular completamente el repositorio; Sin embargo, esto modifica la arquitectura de la aplicación de una manera que podría ser significativa e implica más costos de implementación y mantenimiento.

Lectura adicional

Para obtener más información detallada, consulte Elección de una estrategia de prueba. Para obtener instrucciones de implementación y ejemplos de código, consulte Pruebas en el sistema de base de datos de producción y Pruebas sin el sistema de base de datos de producción.