Oui. Le but est d'utiliser la base de données réelle uniquement pour les tests d'intégration qui ne doivent pas être exécutés aussi souvent et l'ensemble des tests d'intégration est généralement exécuté uniquement sur le serveur de build.
C'est à cause de lente initialisation d'EF lors des tests unitaires (vous pouvez essayer de passer en x86). Le temps est également consommé par la génération de vues. Les vues peuvent être pré-générées ce qui est généralement fait pour réduire le démarrage et l'initialisation du système réel, mais en cas d'accélération des tests unitaires à l'aide de la pré-génération de vue, cela n'aidera pas trop car vous déplacerez simplement le temps du test à la construction.
Faire le tour signifierait simplement utiliser un vieux script SQL. Le temps supplémentaire nécessaire à cette opération peut être consacré à la génération de ce SQL. Je pense que le SQL n'est pas mis en cache car l'exécution normale de l'application n'en a normalement pas besoin plus d'une fois, mais vous pouvez demander à EF de vous donner au moins la partie la plus importante de ce SQL, de le mettre en cache quelque part et de l'exécuter vous-même chaque fois que vous en avez besoin. . EF est capable de vous donner SQL pour les tables et les contraintes :
var dbSql = ((IObjectContextAdapter) context).ObjectContext.CreateDatabaseScript();
Vous avez juste besoin d'avoir votre propre petit SQL pour créer une base de données et les utiliser ensemble. Même quelque chose comme le script suivant devrait suffire :
CREATE DATABASE YourDatabaseName
USE YourDatabaseName
Vous devez également d'abord désactiver la génération de base de données dans le code pour que cela fonctionne et prendre le contrôle du processus :
Database.SetInitializer<YourContextType>(null);
Lors de l'exécution de la création de base de données SQL, vous aurez besoin d'une chaîne de connexion distincte pointant vers Master base de données.
