Unité de test des services de domaine avec une base de données réelle

Question

Je me demandais quelles approches les autres pourraient adopter pour tester les services de domaine par rapport à une base de données? J'ai déjà une série de référentiels factices que je peux utiliser dans les services de domaine pour tester les services de domaine eux-mêmes. Une partie de la construction de ces référentiels factices consiste à créer des échantillons d'agrégats et des entités associées et à les valider par rapport aux mêmes règles commerciales qui seraient sinon utilisées dans le modèle. Cela constitue également un moyen simple et agréable de détecter des points d’impact potentiels au sein des entités elles-mêmes, dans le cas où leurs interfaces changeraient.

Le principal problème que je vois avec les tests en direct de mes référentiels reposant sur SQL est la cohérence de la base de données. Par exemple, une fois qu'un test est exécuté, l'option " create " des aspects ont déjà été exécutés. Leur réexécution entraînerait évidemment des échecs, car la base de données n’est plus vierge. J'envisageais de créer une base de données en miroir utilisée uniquement pour ce type de test. Ce serait minime, structure contenant, programmabilité, contraintes, etc. Je fournirais également un ensemble minimal de données pour certains tests établis. Mon raisonnement est que je pourrais avoir une procédure stockée que je pourrais appeler pour réinitialiser la base de données sur "Pristine". état avec les données de base avant le début du test.

Bien que cela ne soit plus aussi important sur une machine de développeur une fois la fonctionnalité vérifiée, je me penche davantage sur l’importance d’exécuter ces tests dans le cadre de la construction nocturne. de sorte qu'en cas d'échec du test, la compilation puisse être retardée afin de ne pas nuire à l'environnement de déploiement cible (spécifiquement dans ce cas, ce serait l'environnement utilisé par l'équipe de test).

Je ne pense pas nécessairement que la plateforme compte, mais si quelqu'un a des problèmes de mise en œuvre spécifiques, mon environnement se présente comme suit:

Windows 7 (Développement) / Windows Server 2008 R2 (Serveur) Visual Studio 2008 Team Edition (C #) Microsoft SQL Server 2008 Standard (Développement / Serveur)

J'utilise Team Build pour exécuter mes générations, mais ce n'est probablement pas un facteur dans la portée de la question.

Answer 1

  

Par exemple, une fois qu'un test est exécuté, le " create " des aspects ont déjà été exécutés. Leur réexécution entraînerait évidemment des échecs, car la base de données n’est plus vierge.

Peut-être pourriez-vous rendre vos tests unitaires transactionnels. Exécutez vos tests, annulez-les et la base de données reste inchangée.

Spring propose des classes de tests unitaires transactionnels qui facilitent la tâche. Vous avez juste besoin d'un gestionnaire de transactions.

Answer 2

Vous pouvez utiliser SQL Server Express (I ' Nous l’avons fait avec 2005, mais n’avons pas essayé avec 2008) d’installer "Test Deck". bases de données stockées sous forme de fichiers. Celles-ci peuvent être archivées dans le contrôle de code source, puis les classes auxiliaires de test peuvent (a) les copier dans des dossiers temporaires, (b) les activer en écriture et (c) s'y connecter. Pour restaurer l'état d'origine, supprimez la copie temporaire et répétez a-c.

C’est une douleur énorme. Si vous pouvez vous en tirer avec des transactions (comme suggéré par duffymo) J'irais avec cela. Les points douloureux avec les transactions sont des transactions imbriquées et distribuées - surveillez celles de votre code.

Answer 3

Vous pouvez créer un ensemble de fabriques de données dans le code de test, qui s'exécutent initialement au démarrage de votre test. Ensuite, utilisez la méthode d'annulation de transaction pour la conserver en parfait état. Pour faciliter les choses, sous-classez toutes vos classes de test et insérez-y l'accesseur de transaction et le code d'annulation. Le code d'annulation peut être configuré pour s'exécuter automatiquement à la fin de chaque méthode de test.

Answer 4

si vous exécutez des tests unitaires pour votre référentiel qui atteignent une base de données, VOUS NE FAITES PAS DE TEST UNITAIRE. Cela pourrait être un test utile, mais ce n'est pas un test unitaire. C'est un test d'intégration. Si vous voulez faire cela et appeler cela un test d'intégration, c'est très bien. Cependant, si vous suivez de bons principes de conception dans vos référentiels, il n’est pas nécessaire de tester la base de données, JAMAIS, dans vos tests unitaires.

Tout simplement, votre test unitaire de référentiel NE consiste PAS à tester les effets étendus qui se produisent dans la base de données en fonction des entrées dans le référentiel; c’est confirmer que l’entrée dans le référentiel aboutit à un appel à un collaborateur avec tel ou tel ensemble de valeurs.

Vous voyez, le référentiel, comme le reste de votre code, devrait suivre le principe de reposibilité unique. Fondamentalement, votre respoitory a UN et UN SEULEMENT REPOSBABILITÉ, c'est-à-dire qu'il faut résoudre les problèmes d'API de modèle de domaine avec la couche de technologie d'accès aux données sous-jacente (généralement ADO.Net mais cela pourrait être Entity Framework ou L2S ou autre). En prenant comme exemple les appels ADO.Net, votre référentiel ne devrait pas assumer la responsabilité d’être une fabrique pour la couche de données, mais plutôt devenir dépendant d’un collaborateur à partir des interfaces de données ADO.Net (plus précisément IDbConnection / IDbCommand / IDbParameter). etc). Prenez simplement un IDbConnection en tant que paramètre constructeur et appelez-le un jour. Cela signifie que vous pouvez écrire des tests unitaires de référentiel par rapport aux interfaces et fournir des mocks (ou des faux, des stubs ou tout ce dont vous avez besoin) et confirmer que les méthodes requises, dans l'ordre, avec les entrées attendues sont effectuées. Allez consulter mon blog MS sur ce sujet précis - > http: // blogs.msdn.com/b/schlepticons/archive/2010/07/20/unit-testing-repositories-a-rebuttal.aspx

Heureusement, cela vous aidera à commettre une erreur dans vos tests et votre conception à l'avenir.

BTW: Si vous voulez tester un peu la base de données, vous pouvez. Utilisez simplement les tests de base de données Visual Studio. Son construit INTO vs et a été autour depuis VS2005. Ce n'est pas nouveau. Mais je dois vous prévenir, ils doivent être des tests unitaires complètement SEPÉRÉS.

Answer 5

Si votre code est relativement indépendant de la base de données, l'utilisation d'une base de données en mémoire telle que SQLite pour les tests unitaires (et non pour les tests d'intégration) vous apportera les avantages de rapidité et de facilité (vos configurations de test initialisent la base de données).