Sì. Il punto è utilizzare il database reale solo per i test di integrazione che non devono essere eseguiti così spesso e l'intero set di test di integrazione viene solitamente eseguito solo sul server di compilazione.
Ciò è dovuto a lenta inizializzazione di EF durante il test di unità (puoi provare a passare a x86). Il tempo viene consumato anche dalla generazione della vista. Le visualizzazioni possono essere pregenerate che di solito viene fatto per ridurre l'avvio e l'inizializzazione del sistema reale, ma in caso di velocizzazione degli unit test l'uso della pre-generazione della vista non sarà di grande aiuto perché sposterai semplicemente il tempo dal test alla compilazione.
Andare in giro significherebbe semplicemente usare un semplice vecchio script SQL. Il tempo aggiuntivo necessario per questa operazione può essere speso per generare quell'SQL. Penso che l'SQL non sia memorizzato nella cache perché la normale esecuzione dell'applicazione normalmente non ne ha bisogno più di una volta, ma puoi chiedere a EF di darti almeno la parte più importante di quell'SQL, memorizzarlo nella cache da qualche parte ed eseguirlo tu stesso ogni volta che ne hai bisogno . EF è in grado di fornirti SQL per tabelle e vincoli:
var dbSql = ((IObjectContextAdapter) context).ObjectContext.CreateDatabaseScript();
Devi solo avere il tuo piccolo SQL per creare database e usarli insieme. Anche qualcosa come il seguente script dovrebbe essere sufficiente:
CREATE DATABASE YourDatabaseName
USE YourDatabaseName
Devi anche disattivare prima la generazione del database nel codice per farlo funzionare e prendere il controllo del processo:
Database.SetInitializer<YourContextType>(null);
Quando esegui l'SQL di creazione del database, avrai bisogno di una stringa di connessione separata che punta a Master Banca dati.
