Au cours des dernières années, j'ai continuellement lutté avec un code de base de données de test de l'unité et toute la douleur qui l'accompagne. J'ai trouvé ce fil existant que j'ai trouvé très éclairant:
L'auteur de la réponse acceptée suggère qu'il pourrait être utile de se moquer de la couche de base de données complète afin de valider le SQL généré. Je ne pensais pas beaucoup quand j'ai lu la réponse à quelques mois il y a quelques mois, mais j'ai récemment observé plusieurs bugs causés par des champs SQL à tort générés, à tort attribuer à tort, etc. Je me rends compte que JDBC est plutôt gonflé et que l'erreur sujette à utiliser, mais ce n'est pas une option de passer à quelque chose de différent à ce stade.
L'application en question est un processeur de lots de flux de données et utilise JDBC directement plutôt que par une orj. Tout le code JDBC est séparé en objets DAO distincts dans lesquels chaque objet a sa propre interface et son talon, outre les implémentations réelles. Cela m'a permis d'obtenir une bonne couverture de test de la couche d'entreprise, mais le test de la couche de base de données est pratiquement inexistant.
6 Réponses :
Je ne sais pas si vous l'avez vu ou non, mais il y a mokrunner . Il fournit de nombreuses classes qui implémentent les interfaces de JDBC (ainsi que d'autres j2Eeclasses). Voici Les objets Mock JDBC . Il existe également assez de Exemples .
Semble vraiment intéressant. Je vais regarder de plus près et voir si c'est ce que je cherche.
On dirait que vous avez des problèmes dans le code DAO lui-même? Sinon, la couche DAO est l'endroit évident pour faire votre moqueur, mais si vous essayez de tester le DAO, vous devrez alors vous moquer de celui qui vient sous.
Personnellement, j'ai tendance à rester loin de se moquer de grandes bibliothèques complexes; Si vous avez vraiment besoin de tester directement la couche DAO et que le DAO fonctionne directement avec JDBC, vous avez trois choix évidents:
Je choisirais presque toujours # 1 ou n ° 2. Parce qu'il y a une foule de possibilités d'erreurs dans la syntaxe SQL malformée et celle que j'ai tendance à s'appuyer vers # 1. Je me rends compte que ce n'est pas ce que vous demandez. ;)
Comme je l'ai dit dans la question: j'ai déjà des moqueurs de la couche DAO que j'utilise lors du test de la couche d'entreprise. Je vais considérer votre conseil, cependant. Merci pour votre temps. :)
Parfois, j'utilise un appareil à mes daônes à l'aide d'une source de données jetables, en mémoire Hypersonsononicdb. La faille évidente de cette idée est que ce n'est pas une utilisation avec SQL propriétaire de la base de données, mais il est utile de tester des configurations hibernées.
Pendant que je suis un énorme fan de test unitaire en général, je l'ai trouvé de valeur limitée avec DAOS.
Ce que j'ai vu est tout ce qui est tout à fait possible d'écrire les tests (en utilisant l'une des API moqueurs - jmock , EasyMock , etc.), ils fonctionnent généralement tout droit (la logique est si élémentaire comment ne pouvait pas " t ils) seulement rompre lorsque vous modifiez le code (ajout d'une valeur par exemple) et cela en fait un fardeau sur la base de code.
Je pense que c'est parce que mes DAOS suivent généralement la forme:
Vous faites ensuite des hypothèses sur la manière dont le pilote JDBC / fonctionne / est du travail (ING) et que vous obtenez un test qui ne fait vraiment rien que de tester un code simple est appelé dans l'ordre indiqué.
Les erreurs originaires de DAOS se produisent généralement dans la base de données (violations clés, bogues dans les PROC stockés, etc.) et à moins que vous n'écrivez au système dans son ensemble, vous n'allez pas voir ces erreurs.
Ces jours-ci, j'ai tendance à laisser les niveaux supérieurs d'essais - intégration et autres - exercent le code DAO frappant la base de données actuelle en le faisant et, espérons-le, attraper le type d'erreurs que j'ai mentionnées plus tôt que plus tard.
JOOQ navires avec un < un href = "http://www.jooq.org/javadoc/latest/org/jooq/tools/jdbc/mockconnection.html" rel = "nofollow"> Un exemple: Il y a aussi le MockConnection qui peut Soyez fourni avec un MockDataProvider < / a>, ce qui est beaucoup plus facile à mettre en œuvre que l'API JDBC complet. Ce poteau de blog montre comment utiliser la simultanée:
http://blog.jooq.org/2013/ 02/20 / Easy-moqueur-de-votre base de données / MockFileDatabase , qui vous aide à faire correspondre les résultats factices avec SQL Strings en écrivant un fichier texte comme celui-ci:
Si vous souhaitez tester la couche de persistance (ORM, DAO, ...), agissez comme prévu selon divers étuis JDBC (par exemple, lorsqu'il obtient un tel résultat set / mise à jour compte, cela devrait le faire et cela), puis de l'acolyte cadre doit être pris en compte.
Il permet de construire une connexion JDBC que vous gérez à travers Tholler, de sorte que vous choisissez ce qui est renvoyé pour chaque requête / mise à jour: https://github.com/cchantep/acolyte
Divulgation: c'est mon cadre.