Ma question peut sembler vraiment stupide pour certains d'entre vous, mais je dois demander ... désolé ..
Je ne comprends pas vraiment les principes de tests unitaires. Comment pouvez-vous tester des classes de vos classes d'entreprise ou de votre calque d'accès aux données sans modifier votre base de données? J'explique, j'ai une fonctionnalité qui met à jour un champ dans une base de données. Rien n'est aussi incroyable .. La classe de la couche d'entreprise est instanciée et la méthode bll.Unupdate () donne des contrôles et instancier finalement une classe DAL qui lancent une procédure stockée dans la base de données avec les paramètres corrects.
Ses travaux mais ma question est ..
faire des tests d'unité qui testent la classe Dalayer, je dois avoir une incidence sur la base de données dans les tests! Pour tester par exemple si la valeur 5 est bien passée à la base de données, je dois le faire et le champ de la base de données sera 5 après le test!
Donc, je sais normalement le système n'est pas affecté par des tests, je ne comprends donc pas comment vous pouvez faire des tests sans exécuter les méthodes.
TX pour des réponses et excusez mon mauvais anglais ..
4 Réponses :
Pour le scénario, vous décrivez en termes d'interaction dB, la moquure est utile. Si vous avez une chance, jetez un coup d'œil à Rhino Mocks
Vous utilisez Inversion du contrôle avec un cadre moqueur, par ex. Rhino se moque de quelqu'un déjà mentionné
Je vais diviser votre question dans plusieurs sous-questions, car il est difficile de les répondre ensemble.
Test de l'unité X Test d'intégration X / Strong>
Lorsque vous écrivez le test de l'unité, vous testez une unité simple. Cela signifie que vous testez le chemin d'exécution unique dans la méthode testée. Vous devez éviter de tester ses dépendances telles que la base de données mentionnée. Vous écrivez généralement un test d'unité simple pour chaque chemin d'exécution afin que vous ayez une bonne couverture de code par vos tests.
Lorsque vous écrivez le test d'intégration, vous testez toutes les couches pour voir si l'intégration et la configuration fonctionne. Vous n'écrivez généralement pas le test d'intégration pour chaque chemin d'exécution car il existe à de nombreuses combinaisons Cross toutes les couches.
CLASSES D'ENTREPRISE DE TESTES - TEST UNITÉ
Vous devez tester vos cours de votre entreprise sans dépendance à DAL et à DB. Pour ce faire, vous devez concevoir votre classe BL afin que ces dépendances soient injectées de l'extérieur. Vous devez d'abord définir une classe abstraite ou une interface pour DAL et transmettre cette interface DAL comme paramètre sur le constructeur (une autre manière consiste à exposer une propriété de configuration sur la classe BL). Lorsque vous testez votre classe BL, vous utiliserez une autre implémentation d'interface DAL qui ne dépend pas de DB. Il y a des modèles de test bien connus simulés, stub et faux qui définit comment créer et utiliser ces implémentations factices. La moqueur est également soutenue par de nombreux cadres de test.
Couche d'accès aux données de test - Test d'intégration
Vous devez tester votre DAL contre le vrai DB. Vous préparerez des tests DB avec un ensemble de données de test et vous écrirez vos tests pour travailler avec ces données. Chaque test fonctionnera dans sa propre transaction qui sera renvoyée à la fin afin qu'il ne modifiera pas le jeu de données initial.
Cordialement, Ladislav
Si vous ne recez pas à la moqueur et à l'utilisation de la DB réelle dans les tests, il s'agira d'un test d'intégration en lameman et que ce n'est plus un test unitaire. J'ai travaillé sur un projet où un SQLDF dédié était dans le contrôle de la source qui a été attaché au serveur de base de données à l'aide de Nunit dans [Configuration] partie de [Setupfixture], Similary détaché dans [Détruire]. Cela a été fait à chaque test de Nunit a été effectué et pourrait prendre beaucoup de temps en fonction du code SQL que vous avez ainsi que de la taille des données peut s'aggraver.
Maintenant, la capture est la tenue de maintenance, vous pouvez modifier la SCEHMA DB pendant votre cycle de sprint et sur Release, le script de modification DB doit être exécuté sur toutes les bases de données utilisées dans votre développement et votre test, y compris celui utilisé pour les tests d'intégration. mentionné ci-dessus. Non seulement cela, de nouvelles données de test (comme une personne mentionnée ci-dessus) doivent être voloulées pour de nouvelles tables / colonnes créées et également, les données Exisitng doivent devoir être nettoyées également en raison de modifications des exigences ou de corrections de bugs.
Cela semble être une tâche en soi et une personne compétente en équipe peut prendre la propriété ou si le temps le permet, vous pouvez intégrer l'exécution des scripts de changement dans l'intégration continue si vous en avez déjà implémenté un. Toujours l'ajout et le nettoyage des données de test doivent être pris en charge manuellement.