Test di applicazioni EF Core

Il test è un problema importante per quasi tutti i tipi di applicazioni: consente di assicurarsi che l'applicazione funzioni correttamente e segnala immediatamente eventuali regressioni future del comportamento. Poiché i test possono influire sul modo in cui viene progettato il codice, è consigliabile pianificare i test in anticipo e garantire una buona copertura man mano che l'applicazione evolve. Questa sezione introduttiva offre una rapida panoramica delle varie strategie di test per le applicazioni che usano EF Core.

Coinvolgimento del database (o meno)

Quando si scrivono test per l'applicazione EF Core, una decisione di base da prendere consiste nel determinare se i test coinvolgeranno il sistema di database di produzione, proprio come fa l'applicazione, o se i test verranno eseguiti su un duplicato di test, che sostituisce il sistema di database di produzione. Due esempi importanti di duplicati di test nel contesto di EF Core sono SQLite in modalità in memoriae il provider in memoria.

Per un confronto approfondito e l'analisi dei diversi approcci, vedere Scelta di una strategia di test. Di seguito è riportato un breve riepilogo dettagliato per illustrare rapidamente le diverse opzioni:

• Gli sviluppatori spesso evitano di eseguire test sul sistema di database di produzione perché ritengono che questo approccio sia difficile o lento. L'esperienza dimostra che questo non è sempre vero ed è quindi consigliabile provare a usare questo approccio: il test sul sistema di database di produzione fornisce tecniche per eseguire questa operazione in modo affidabile ed efficiente. La scrittura di almeno alcuni test sul database è in genere necessaria in qualsiasi caso, per assicurarsi che l'applicazione funzioni effettivamente sul database di produzione, e i test che non coinvolgono il database possono essere limitati a livello di elementi che possono essere testati, come indicato di seguito.
• Il provider in memoria non si comporta come il database reale in molti modi importanti. Alcune funzionalità non possono essere testate con questo approccio, ad esempio transazioni e SQL non elaborato, mentre altre funzionalità possono comportarsi in modo diverso rispetto al database di produzione, ad esempio la distinzione tra maiuscole e minuscole nelle query. Anche se l'approccio in memoria può funzionare per scenari di query semplici e vincolati, è altamente limitato ed è sconsigliabile usarlo.
  • La simulazione di DbSet per l'esecuzione di query è complessa e difficile e presenta gli stessi svantaggi dell'approccio in memoria. Anche questo approccio è quindi sconsigliato.
• La modalità SQLite in memoria offre una compatibilità migliore con i database relazionali in produzione, poiché SQLite stesso è un database relazionale completo. Esisteranno tuttavia comunque alcune discrepanze importanti tra SQLite e il database di produzione e non sarà possibile testare alcune funzionalità, ad esempio metodi specifici del provider in EF.Functions.
• Per un approccio di test che consente di usare un duplicato di test affidabile per tutte le funzionalità del sistema di database di produzione, è possibile introdurre un livello di repository nell'applicazione. Ciò consente di escludere completamente EF Core dal test e di simulare completamente il repository; Questo approccio modifica tuttavia l'architettura dell'applicazione in modo significativo e comporta costi di implementazione e manutenzione maggiori.

Altre risorse

Per informazioni più approfondite, vedere Scelta di una strategia di test. Per linee guida di implementazione ed esempi di codice, vedere Test sul sistema di database di produzione e Test senza il sistema di database di produzione.