Prueba de aplicaciones EF Core

Las pruebas son una preocupación importante para casi todo tipo de aplicaciones: permiten asegurarse de que la aplicación funciona correctamente y hace que sepa al instante si este comportamiento se repite en el futuro. Dado que las pruebas pueden afectar a la forma en que se diseña el código, se recomienda encarecidamente planear una prueba temprana que garantice una buena cobertura a medida que evoluciona la aplicación. En esta sección introductoria se proporciona una introducción rápida a las diversas estrategias de prueba para las aplicaciones que usan EF Core.

Que impliquen la base de datos (o no)

Al escribir pruebas para su aplicación EF Core, debe decidir si las pruebas implicarán al sistema de base de datos de producción (igual que la aplicación) o si las pruebas se ejecutarán con un doble de prueba, que reemplazará al sistema de base de datos de producción. Dos ejemplos destacados de dobles de prueba en el contexto EF Core son el modo in-memory de SQLite y el proveedor in-memory.

Para obtener una comparación detallada y un análisis de los distintos enfoques, consulte Elección de una estrategia de pruebas. A continuación se muestra un breve resumen punto por punto que le ayudará a agilizar las distintas opciones:

• Los desarrolladores suelen evitar las pruebas en su sistema de base de datos de producción porque creen que es un proceso difícil o lento. Según nuestra experiencia, no siempre es cierto y se recomienda dar una oportunidad a este enfoque: Las pruebas en el sistema de base de datos de producción proporcionan técnicas para llevarlo a cabo con confianza y eficacia. Suele necesitarse la escritura de al menos algunas pruebas en la base de datos en cualquier caso (para asegurar 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 limitar lo que le permiten probar (consulte lo siguiente).
• El proveedor in-memory no se comportará como la base de datos real en muchas de las formas que resultan importantes. Algunas características no se pueden probar (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, la diferencia entre mayúsculas y minúsculas en las consultas). Aunque in-memory puede funcionar en supuestos de consulta sencillos y restringidos, está muy limitado y no se recomienda su uso.
  • La simulación DbSet para la consulta es compleja y difícil, y se ve afectada por las mismas desventajas que el enfoque in-memory. Esto también se desaconseja.
• El modo en memoria de SQLite ofrece una mejor compatibilidad con las bases de datos relacionales de producción, ya que SQLite es en sí una base de datos relacional completa. Sin embargo, seguirá habiendo discrepancias importantes entre SQLite y la base de datos de producción, y no hay forma alguna de probar ciertas características (por ejemplo, métodos específicos del proveedor en funciones EF.).
• Para un enfoque de prueba que le permita usar un doble de prueba confiable para toda la funcionalidad del sistema de base de datos de producción, es posible introducir una capa de repositorio en la aplicación. Esto le permite excluir los EF Core de las pruebas y simular el repositorio completo; sin embargo, modificará la arquitectura de la aplicación de una manera que podría ser significativa e implica más costos de implementación y mantenimiento.

Información adicional

Para obtener información más detallada, consulte Elección de una estrategia de pruebas. 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.