Je pensais faire un nouveau, de poids léger, de la base de données de la population cadre. J'ai vraiment la haine dbunit. Avant de le faire, je veux savoir si quelqu'un l'a déjà fait.
Des choses que je n'aime pas à propos de dbunit:
1) Le plus simple format d'écrire et de commencer est obsolète. Ils veulent que vous utilisez les formats de ballonnement. Certains exigent même des schémas xml. Ouais, c'est ça.
2) Ils peuplent les lignes pas dans l'ordre que vous les écrire, mais dans l'ordre des tableaux sont définis dans le fichier xml. C'est vraiment mauvais parce que vous ne pouvez pas commander vos données d'une façon telle que les contraintes de clé étrangère ne cause pas de problèmes. Cette juste vous oblige à passer par les tracas de les désactiver complètement.
Cela a également des pertes de temps et gonfle votre junit classes de base pour inclure le code pour désactiver les contraintes de clé étrangère. Vous aurez probablement à tester pour le type de base de données (hsqldb, etc.) et de les désactiver dans la base de données de manière spécifique. C'est la façon dont mauvais.
Il pourrait être mieux si dbunit aidé dans la désactivation des contraintes de clés étrangères dans le cadre de leur cadre automatiquement, mais ils ne le font pas. Ils n'garder une trace de dialectes... alors pourquoi ne pas les utiliser pour cela? En fin de compte, tout cela n'est de forcer le programmeur à perdre du temps et de ne pas obtenir et de le tester rapidement.
3) XML est une douleur à écrire. Je n'ai pas besoin d'en dire plus à ce sujet. Ils offrent également de nombreuses façons de le faire, que je pense qu'il complique les choses. Juste offrir un vraiment de manière solide et être fait avec elle.
4) Lors de vos données est grande, garder une trace de la carte d'identité et la cohérence de leur/relations correctes est une douleur royale.
Aussi, si vous ne travaillez pas sur un projet pour un mois, comment êtes-vous de se rappeler que user_id 1 a été un admin, user_id 2 a été une entreprise de l'utilisateur, user_id 3 était un ingénieur et user_id 4 a été quelque chose d'autre? Retour à la case c'est perdre plus de temps. Il devrait y avoir un moyen de récupérer, à l'exception d'un nombre arbitraire.
5) C'est lent. J'ai trouvé que moins de hsqldb est utilisé, il est très lent. Il n'a pas à être. Il existe aussi de nombreuses façons de gâcher sa configuration, comme il n'est pas facile à faire "out of the box". Il y a une bosse que vous devez faire pour obtenir le droit de travailler. Cette fonction ne fait qu'encourager les gens à ne pas l'utiliser, ou d'être énervé quand ils commencent à l'utiliser.
6) Certaines valeurs ont tendance à se répéter beaucoup, aime dates. Il serait bien de spécifier les valeurs par défaut, ou même avoir le cadre mis par défaut automatiquement, même sans vous dire de mettre des valeurs par défaut. De cette façon, vous pouvez créer des objets avec les valeurs que vous voulez, et de laisser le reste off. Ce que bat la spécification de tous les coins et recoins d'une colonne si elle n'est pas requise.
7), Probablement le plus ennuyeux est que la première entrée doit inclure TOUTES les valeurs null même des espaces réservés ou futures lignes à ne pas choisir les colonnes que vous avez spécifié.
DBunit n'ont pas de valeur par défaut raisonnable pour la traduction [NULL] pour une réelle valeur null. Vous devez l'ajouter manuellement. Dites-moi, qui n'a pas fait cela avec dbunit? Tout le monde a des. Il ne devrait pas être comme ça!
Ce que cela signifie est que si vous avez un objet polymorphe, vous devez déclarer toutes les clés étrangères à la jointure de tables de chaque sous-classe dans la première ligne, même si elles sont nulles. Si vous faites un tableau pour toutes les classes de modèle, vous devez toujours spécifier tous les champs sur la première ligne. C'est juste horrible.
Quelque chose pour me satisfaire, ou devrais-je devenir le prochain cadre développeur d'une bien meilleure base de données framework de test?