Impossible d'utiliser la base de données existante dans les tests unitaires avec la structure Effort
c# effort entity-framework entity-framework-6 unit-testing
Question
J'essaie d'écrire un test à l'aide d'une base de données hébergée dans Azure SQL avec Framework Effort sur Entity Framework 6.
Lors de l'exécution du code suivant, une exception est levée:
[ClassInitialize]
public static void ClassInitialize(TestContext context)
{
EffortProviderConfiguration.RegisterProvider();
}
[TestMethod]
public void TestMethod1()
{
const string connectionString = "Data Source=***;Initial Catalog=my_catalog;User ID=user;Password=password;provider=System.Data.SqlClient";
IDataLoader loader = new EntityDataLoader(connectionString);
using (var ctx = new UsersDbContext(Effort.DbConnectionFactory.CreatePersistent("cool", loader)))
{
var usersCount = ctx.Users.Count();
}
}
Exception levée lors de l'exécution de Count() :
Effort.Exceptions.EffortException: exception non gérée lors de la tentative d'initialisation du contenu de la table 'Table' ---> System.ArgumentException: Mot clé non pris en charge: 'source de données'.
La même exception est levée lors du remplacement de EffortProviderConfiguration.RegisterProvider() par les paramètres app.config.
Lorsque vous utilisez exactement la même chaîne de connexion pour la création de UsersDbContext , les résultats sont accessibles et les données sont accessibles. De plus, la création de contexte avec le mode Effort persistant ou transitoire, sans chaîne de connexion, fonctionne également.
Que faut-il faire pour initialiser une connexion avec des données existantes à partir d'une base de données réelle?
Réponse populaire
Si, comme moi, vous ne comprenez pas pourquoi vous devez attribuer à Effort une chaîne de connexion (puisqu'elle fonctionne sur une base de données en mémoire et que vous fournissez directement votre contexte à une connexion), la documentation le rend un peu plus clair - c'est requis uniquement si vous utilisez des variantes de la base de données ou du modèle d'abord d'Entity Framework, car la chaîne de connexion Entity fournit les informations nécessaires à Effort pour localiser votre modèle afin qu'il puisse en générer un! Vous pouvez donc remplir en toute sécurité les parties serveur / base de données / ID utilisateur / mot de passe de la chaîne de connexion avec des noms factices.
Cela montre également que l'approche DbConnectionFactory par défaut personnalisée ne fonctionne que pour le code en premier, ce qui explique les premières heures d'erreur que je recevais ... Pour un modèle ou une base de données en premier, vous devez injecter une entité Entity Connection dans votre classe d'entité. , comme décrit ici .
Conseil utile: comme votre classe de modèle d’entité générée est une classe partielle, vous pouvez créer un autre fichier de code dans le même assemblage, lui attribuer le même espace de nom et en faire également une classe partielle. Vous pouvez également ajouter le second constructeur nécessaire pour définir la EntityConnection à ce fichier de code à la place. Ainsi, lorsque vous modifiez / recréez votre modèle d'entité, le code avec le constructeur personnalisé ne sera pas supprimé par le modèle t4.