DAO Unit test

J'ai été à la recherche à EasyMock et des tutoriels et des exemples autour de l'utiliser pour les Tests Unitaires des classes DAO, pour un "dehors" conteneur de test. Cependant, je pense que la plupart d'entre eux parlent sur les tests de la Couche de Service au lieu de cela, se moquant de la classe DAO. Je suis un peu confus, c'est vraiment la façon dont vous l'Unité de Test de la couche DAO?

Certains diront que les tests d'interaction avec DB & les Ejb sont en fait des tests d'Intégration et de ne pas les tests Unitaires mais alors, comment voulez-vous savoir si votre SQL est correcte (en supposant qu'aucun ORM) et votre DAO insertions/requêtes les bonnes données à partir de votre réel (lire, base de données locale qui est similaire à celle de la production) de la base de données?

J'ai lu que DBUnit est une solution pour une telle situation. Mais ma question est à propos de l'utilisation d'un framework comme DBUnit "à l'extérieur du conteneur". Que faire si le DAO dépend d'un Ejb, comment pouvons-nous gérer les transactions, ce qui se passe si il ya des déclencheurs qui mettent à jour les autres tables sur vos semelles?

Quel est le meilleur moyen de l'Unité de Test uniquement le DAOs avec ces dépendances?

source d'informationauteur dchucks

  1. 23

    Personnellement, je test unitaire DAOs en appuyant sur une sorte de base de données de test, de préférence le même type de base de données (pas la MÊME base de données, évidemment) que votre application utilise dans la production.

    Je pense que si vous faites ça, le test est plus un test d'intégration, parce qu'il a une dépendance sur une base de données. Cette approche a l'avantage, en ce qu'il est aussi proche que possible de votre environnement de production. Il a les inconvénients que vous avez besoin de tester la configuration, vous avez besoin d'un test en cours d'exécution de base de données (local de votre machine ou quelque part dans votre environnement) et les tests peuvent prendre plus de temps pour s'exécuter. Vous devez également être sûr de restaurer les données d'essai d'après les tests à exécuter.

    Une fois DAOs sont testés, certainement se moquer d'eux à l'unité de test de vos services.

  2. 12

    Généralement avec DAOs l'idée est d'avoir un minimum d'enveloppe code d'accès aux données, donc il n'y a rien là pour tester, sauf pour la cartographie de la base de données, et les tests unitaires avec des objets fantaisie sont inutiles. Si il est en fait logique dans le DAO essai de la valeur avec des objets fantaisie, alors un argument peut être faite que vous êtes un mauvais usage du pattern DAO et que la logique devrait être en service.

    Pour l'examen de la cartographie de la base de données DBUnit est utile, car elle vous permet de spécifier un départ dataset avant le test afin que votre test démarre à partir d'un état connu, et il vous permet de spécifier ce que la fin de l'état des données devrait être, de sorte que vous n'avez pas à écrire beaucoup de code de test unitaire affirmant qu'est ce qu'il y a ce qui est attendu.

    Idéalement si vous disposez d'un outil comme Hibernate qui fait abstraction de la base de données plus loin, vous pouvez vous en tirer avec l'aide d'une base de données en mémoire comme H2 ou HSQLDB, de sorte que vos tests de courir plus vite et il n'y a pas de base de données à créer. Si vous avez de l'utilisation d'une base de données assurez-vous que vos tests ont pour eux-mêmes afin de créer et de supprimer des données sans affecter ou être affectés par d'autres processus. Dans la pratique, d'avoir une base de données pour vous-même, à la fois localement et dans CI environnements, il est peu probable et l'utilisation de la base de données en mémoire est beaucoup plus pratique.

  3. 2

    Je suis à l'aide de HSQLDB pour Dao et de Service de l'API de test. Le rendement est bon et il prend en charge les transactions. Je ne suis pas à l'aide d'EJB. J'utilise Hibernate.

    Il y a quelques questions que je suis conscient du fait que l'exécution de tests sur une autre base de données peuvent masquer certains problèmes de base de données pris en charge. Mais je pense que ces questions devraient être pris dans la fumée & tests d'acceptation.

    ce qui concerne,
    Koya

  4. 2

    Complétant sur Koya anwers, vous pouvez utiliser HSQLDB pour DAO essai. J'imagine que vous avez l'utilisation de Spring et Hibernate dans votre projet. Vous devez séparer les fichiers de configurations à point pour la HSQLDB, vous devez insérer des données avant l'exécution des tests. Il y a quelques limites à ce que vous pouvez faire avec HSQLDB, mais il est OK pour un usage général en tant que requêtes et des jointures. Avec cette solution peut être utilisée en continu de l'environnement , tels que jenkins.
    Les tests d'intégration pourrait utiliser le HSQLDB , cette partie ne se moque pas.

  5. 1

    J'ai finalement réglé à l'écriture des tests Unitaires qui peuvent s'exécuter à l'extérieur du récipient, avec une base de données et de prise en charge transactionnelle utilise autonome gestionnaire de transactions (Bitronix), je suis en mesure de restaurer aussi. Je suppose que ce n'est pas faire le test Pur tests Unitaires encore...aimerais connaître votre opinion des gens sur cette approche.