Unité testant le DAL - veuillez critiquer

Question

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

je essentiellement une classe appelée FooDataAccess avec plusieurs fonctions très simples, disons trois d'entre eux comme ceci:

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

Ce que je faisais était ce - mettre 4 Scripts SQL dans mon projet de test unitaire, le dernier un comme ressource incorporée.

1) Créer (test unitaire) Script de base de données, 2) Créer des objets Script, 3) Insérer des valeurs de consultation de table et 4) Supprimer tout Mais une Table Valeurs

L'idée est, tout le monde en utilisant d'abord le projet devrait manuellement exécuter les scripts 1-3 à la main en tant que configuration unique. Ensuite, exécuter le script # 4 au démarrage de chaque test unitaire ... (dans les petites applications, vous pouvez même exécuter tous au niveau de test)

OK, so far so good ...

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

Où je 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.

Serait-il logique d'abandonner temporairement toutes les contraintes de clé étrangère pour la portée de mon test? Sinon, pour tester la fonction InsertFoosDepedency (int fooID, string someValue), je devrais d'abord exécuter arbitrairement sql (insérer manuellement un enregistrement dans la table FOO et retourner le FooID) ...

OU, devrais-je juste faire le dernier?

Tous les commentaires sont grandement appréciés. MISE À JOUR: Son fonctionnement proprement avec SQL en ligne pour créer les dépendants. Je suppose que je suis juste à la recherche de commentaires & critisism sur cette méthode pour les tests unitaires DAL. Merci encore

Answer 1

Cela semble assez similaire à ce que je fais. Je détruis toutes les données dans la base de données au start of each test et puis construisons exactement ce que ce test nécessite dans 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, vos noms de méthode suggèrent C#, donc je vais vous signaler à dbUnit.Net mais je ne l'ai jamais utilisé cela. Cela fournit une méthode plus agréable (IMO de toute façon) de peupler la base de données et de vérifier le contenu de la base de données.

Answer 2

Je dirais jamais muck autour de votre schéma pour les besoins des tests. Si vous ne parvenez pas à le remettre ou votre code pour le remettre en panne, vous vous retrouverez dans un désordre très rapidement.

Pouvez-vous utiliser Mock Objects? Si non, je pense que tout ce que vous pouvez faire est de configurer des pré-requis 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 les bonnes conditions pour les tests.

Ou vous avez juste à faire votre configuration spécifique au test dans la méthode de test (et vous pourriez utiliser Teardown pour vider le DB par la suite).