Bonjour,

Je suis en train de bosser sur une application Spring+Hibernate+Oracle et j'ai un pépin au moment d'exécuter des tests unitaires sur mon service Spring : il l'annonce une violation de contrainte unique sur une base vide !

Voici l'extrait du log de JBoss concerné :


Le hic, c'est que je ne vois absolument pas à quoi corresponf cette table OGS_TEST.SYS_C004434 (ça a l'air d'être un index, mais pourtant je vide ma base de données et je recrée le schéma avant chaque exécution des tests).

Et le plus frustrant, c'est que la toute première fois que j'ai fait tourner ce test sur la base OracleXE toute fraichement installée, ça a marché sans couac. Et depuis plus rien. J'ai bien essayé de droper le schéma correspondant et de le recréer, mais ça n'a rien changé.

Des idées ? Parce que moi j'y perds mon latin.

Le mieux c'est de regarder à quoi correspond OGS_TEST.SYS_C004434 dans ta base de donnée.

Connecte toi sur ta base de données et tape:

T'aura tout les détails pour te donner une idée de ce qui coince.

Petite faute dans la requete SQL (faut pas de '.' devant SYS_, erreur copier coller)

Tant que j'y pense, çà s'est produit avec mon collègue, il a fait ceci (en gros et si ma mémoire est bonne):

1) Récupérer un objet Hibernate
2) Filer ses propriétés à un client pour édition:

3) Après édition, updater l'objet de la manière suivante:


La bonne démarche pour le point 3 doit être:

En fait, le problème venait d'une erreur dans mon modèle UML qui, par le truchement d'AndroMDA, s'était trouvée répercutée dans le code DDL pour la création de la base, avec une contrainte d'unicité qui n'avait rien à faire là. Enfin bre, comme que les tests unitaires JUnit permettent aussi de signaler des erreurs de modélisation :P

Merci quand même.

Tu peut m'éclairer sur ce sujet? Pour le moment j'utilise les tests unitaire pour vérifier la conformité du code vis à vis du design, pas pour vérifier la logique du design!

Grâce à AndroMDA, je n'ai pas besoin de vérifier la conformité de mon code avec mon design : elle est assurée par le processus de génération, qui génère entre 80 et 90% du code de mon application à partir de mes modèles UML indépendants de la plateforme (PIM). De mon côté je n'ai plus qu'à implémenter le code qui est vraiment spécifique à l'application : méthodes business pour les services Spring et quelques méthodes utilitaires pour les entités Hibernate. Résultat des courses, les tests ne sont vraiment utiles que sur cette partie du code, et servent à vérifier le code en lui-même.

Là en l'occurence c'est allé un peu plus loin que ça, puisque dans mon modèle, j'avais oublié de spécifié une multiplicité sur une fin d'association. Résultat, le générateur a présumé que cette multiplicité était 1, et il en a déduit que j'avais une contrainte d'unicité sur le champ correspondant à cette fin d'association dans la base de données. Du coup quand j'ai compris à quoi servait l'index qui me ressortait l'erreur de violation d'unicité, et notamment sur quel champ il portait, je suis allé voir le code DDL (généré à partir des fichiers hbm.xml par hbm2ddl) pour me rendre compte qu'il y avait une roubignole dans le potage. Et comme les fichiers HBM sont eux aussi générés directement à partir du modèle UML, le problème venait forcément du modèle. CQFD.

Ca fait beaucoup de génération tout ça, mais on voit tout de suite l'avantage quand on se rend compte que ça permet de minimiser l'intervention humaine et donc les sources d'erreurs potentielles, notamment au niveau des différents niveaux de transformations : modèle -> classes, classes -> design patterns, classes->fichiers de configuration, fichiers de configuration->DDL, etc. L'autre avantage bien sur, c'est qu'en l'occurence, il m'a suffi de corriger mon modèle et de regénérer les fichiers concernés pour corriger l'erreur : pas besoin d'assurer manuellement la cohérence entre tout ce petit monde.

Bref, c'est vraiment dommage que MDA en général et AndroMDA en particulier soient aussi... méconnus ou malmenés, parce que c'est une démarche vraiment très puissante qui accélère grandement les développements et permet d'obtenir un code de qualité tout en se concentrant sur l'essentiel : penser à l'application en termes de ce qu'elle doit faire, et non pas de comment elle doit le faire. A méditer.

Merci pour l'info, je suis sur que çà me sera un jour très utile :)