Unité testant le DAL - merci de critiquer

Question

Je suis au point dans mon projet simple où je suis prêt à tester le DAL à l'unité.

En gros, j'ai une classe appelée FooDataAccess avec plusieurs fonctions très simples, disons que 3 d'entre elles sont comme ceci:

int InsertFoo(string fooName)
void UpdateFoo(int fooID, string fooName)
void InsertFoosDepedency(int fooID, string someValue)

Voici ce que j’ai fait: 4 scripts SQL ont été insérés dans mon projet de test unitaire, le dernier en tant que ressource incorporée.

1) Créer un script de base de données (test d'unité), 2) Créer un script d'objets, 3) Insérer les valeurs de la table de recherche et 4) Supprimer tout sauf les valeurs de la table de recherche

L'idée est que toute personne utilisant le projet en premier devrait manuellement exécuter les scripts 1 à 3 à la main en tant que configuration unique. Ensuite, exécutez le script n ° 4 au démarrage de chaque test unitaire ... (dans les petites applications, vous pouvez même les exécuter toutes au niveau des tests)

OK, jusqu'ici tout va bien ...

J'ai donc la configuration de ma base de données de test unitaire, comme une ardoise vide. Tester la première fonction InsertFoo () est évidemment très simple. J'appelle la fonction, puis assert simplement (ExecuteSQL ("select count (*) from foo") > 1), Assert (ExecuteSQL ("select fooName de t_foo ") = attendu)), etc ..

Là où je suis un peu coincé, ce sont ceux qui nécessitent des dépendances, comme la 3ème fonction dans mon exemple, ou même la mise à jour.

Est-il judicieux de supprimer temporairement toutes les contraintes de clé étrangère pour la portée de mon test? Sinon, pour pouvoir tester la fonction InsertFoosDepedency (int fooID, string someValue), il faudrait d’abord exécuter un SQL arbitraire (insérer manuellement un enregistrement dans la table FOO et renvoyer le FooID) ...

OU, devrais-je faire ce dernier?

Tous les commentaires sont grandement appréciés.

UPDATE: il fonctionne correctement avec du SQL intégré pour créer les dépendants. Je suppose que je suis juste à la recherche de commentaires & amp; critique sur cette méthode pour les tests unitaires DAL. Merci encore

Answer 1

Cela ressemble assez à ce que je fais. Je détruis toutes les données de la base de données au à partir du début de chaque test , puis je construis exactement ce que ce test nécessite lors de la phase de configuration des tests. Donc, pour UpdateFoo , j'aurais

void update_existingKey_updatesValue() {
   String expected = "jeff";

   clearDatabase();
   // Note I would use dbUnit.
   executeSQL("insert into foo values (1, 'fred')");

   DAL subject = new DAL(...);
   subject.update(1, expected);  

   //Note I would use dbUnit.   
   String actual = executeSQL("select name from foo where id = 1"); 
   assert(expected, actual);
}

En Java, j'utilise un outil appelé dbUnit , les noms de vos méthodes suggèrent C #, donc je vous oriente sur dbUnit.Net , mais je ne l'ai jamais utilisée. Ceci fournit une méthode plus agréable (IMO anyway) pour renseigner la base de données et en vérifier le contenu.

Answer 2

Je dirais que jamais ne traitez pas votre schéma pour des raisons de tests. Si vous ne parvenez pas à le restaurer ou si votre code échoue, vous vous retrouverez très vite dans le pétrin.

Pouvez-vous utiliser les Mock Objects ?

Si non, je pense que tout ce que vous pouvez faire est de configurer les pré-requêtes de base de données pour chaque test.

Vous pouvez envisager une classe distincte pour chaque test et utiliser les méthodes Setup et Teardown pour obtenir la base de données dans le bon état pour les tests.

Ou vous devez simplement effectuer votre configuration spécifique au test dans la méthode Test (et vous pouvez utiliser Teardown pour vider le DB par la suite).