Discussion :

[nicdo77]

Bonjour
Non ceci n'est pas un sondage pour savoir quel est le mieux entre JUnit et TestNG pour les tests.
Non j'ai un vrai contexte que je vais vous présenter et ma question est plus générale que çà: je veux dire, il me faut une solution générale.

Alors allons-y.
Donc ce qu je veux c'est faire des unit-tests sur mes services Spring et mes DAO.

Mon environnement: j'utilise l'IDE IntelliJ, Maven2, Hibernate 3.1.3, Spring 1.2.9 et AndroMDA 3.2 pour la génération des DAO, entity beans, VO, fichiers de mapping Hibernate etc etc etc...

Je veux tester mes services et DAO par rapport aux données manipulées et renvoyées: dnc data-driven et non behaviour-driven.

J'aimrais être indépendant de l'environnement: en prod on utilise MySQL5 mais pour les tests unitaires je veux qqch de facile à mettre en place : l'idée c'est que si je mets l'environement de test en place, mon collègue puisse le récupérer via Subversion et que les tests passent également chez lui (en tout cas ce serait l'idéal). Donc je pensais un peu à HSQL, mais y a peut-etre d'autres solutions.

Je veux pouvoir lancer mes tests via mon IDE (lancer chaque unit test séparément, puis ensemble, puis... pour l'instant j'utilise Junit 3.8.1 integré à IntelliJ, mais çà peut changer). Ces tests doivent être lancés dans Maven2 également: il s'agit du goal test.

Sinon, j'ai des données de test. Je veux pouvoir injecter celle-ci facilement pour mes tests, et les retirer à la fin si j'en ai envie (ou au moins que l'insertion des données de test soient intelligentes). Ces données peuvent être chargées à l'execution ou pré-chargées avant. Enfin pouvoir faire un rollback général serait un plus (mais je sais pas encore si çà me servirait).

Enfin je veux qqch de si possible simple à mettre en oeuvre. On a une deadline dans un mois et comme on est un peu en retard, on commence à se demander si on ne va pas repousser les unit tests plus tard (no comment, on a pas le choix). On se limiterait alors au test d'intégration. Quand je dis "facile à mettre en oeuvre", ca reprend ce que j'ai dit plus tot: suffit que je commite tout l'environnement sur mon SVN, mon collègue récupère et çà marche? ce serait parfait.

Donc voilà. J'ai déjà pensé à qq solutions mais je "débute" donc je ne sais pas si ces solutions seraient judicieuses + certaines me paraissent délicates à mettre en oeuvre:
- HSQL in-process (fichier .script) et JUnit: mais on dépend alors du fichier de DB... et pour l'instant je parviens pas à faire fonctionner le in-process avec un chemin de DB relatif. Puis bon, y a tjs le pb de la mise à jour du schéma de base.
- HSQL in-memory + Junit: on doit quand mem remplir la base. Je crois qu'avec une bonne grosse requete bien grasse on peut le faire (genre récupérer un script sql et l'executer dans un statement.execute(..)). Mais çà pose tjs le pb de la mise à jour de la DB.
- Unitils, c'est un framework de unit tests, open source, qui combine JUnit, DB Unit, les applicationContext de Spring, Hibernate; breef çà semble puissant mais c'est jeune encore. J'ai un peu peur de perdre du temps à appréhender la bête? Et serait-ce intégrable dans Maven2?
- DBUnit et HSQL? mais j'ai enore du mal à comprendre DbUnit et je suis pas sûr que çà remplirait mes besoins.

Voilà je suis open. Jai peut etre zappé des solutions.
Bref j'attends vos conseils/questions/suggestions.

Merci d'avance.
Nicolas.

PS: et je suis bien conscient qu'on peut pas tout avoir, donc je suis prêt à faire des compromis si il le faut.

PPS: et j'ai d'ailleurs un problème dans l'utilisation de HSQL: le dialect Hibernate est par défaut à <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop> dans mon applicationContext.xml (normal vu que ma base de prod est MySQL) mais j'aimerais pouvoir mettre ce dialecte à HSQL pour les tests. Or je ne parviens pas à le faire via le code. J'ai essayé de mettre un applicationContext-test.xml où je copie-colle l'autre applicationContext et j'y change juste le hibernate.dialect... mais on m'a dit que c'est moyennement propre...

[gifffftane]

Moi je trouve bien la séparation tests unitaires / tests d'intégrations. Surtout que les tests unitaires sont souvent faciles à faire, alors pourquoi s'en priver même si on est un peu léger sur l'intégration ?

Et je trouve bien aussi de réfléchir à la pertinence d'un test : est-il vraiment utile de tester le résultat d'une requête SQL ? ou de vérifier si Spring instancie le bon singleton ?

De plus, en phase tendue, il me semble bon de réfléchir à ce qui peut être vraiment utile à surveiller... ce qui est vraiment sensible, qui pourrait faire capoter le projet. Par exemple, sur un programme de compta, il ne faut pas se gourrer dans les calculs. Et pour vérifier si les calculs sont bons, aucun besoin de faire intervenir une base de données.

[hugo123]

Salut,

Nous avons exactement la même problématique et nous l'avons résolu avec les outils dont tu parles. En gros voici ce que ca donne :
Nous avons des tests unitaires de services qui testent des DAO Mock (fausse données) injecté via spring
Nous avons des tests unitaires de DAO avec une base de données embarquées (Derby) démarré dans le test et peuplé avec DBUnit. Les tests unitaires font une comparaison entre l'état de la base avant et après grace a l'api DBunit.
Comme il n'y a pas besoin de base externes, n'importe qui peut checkouter ce code et l'executer même sans être au boulot, ca marche.
Après il y a aussi des tests d'intégration qui reprennent les mêmes tests mais avec un paramétrage spring différent pour pointer sur une base mysql et donc jouables uniquement sur notre réseau. A noter cependant qu'il existe un patch cargo pour embarquer mysql dans les containers qu'il peut démarrer, donc bientot il sera tout aussi simple de faire du test unitaire avec un mysql démarré par cargo dans la phase de test.

Par rapport a tes questions sur DBUnit, c'est exactement ce qu'il te faut. L'api te permet de charger ton jeu de test initial au démarrage. Le schéma est créé par hibernate avec son hbm2ddl au démarrage.

Pour ce qui est de ta question sur ton applicationContext, j'ai du mal a voir comment vous fonctionnez mais tu sembles indiquer que c'est le même pour les tests et la prod ? Je ne vois pas en quoi c'est pas très propre de jouer des tests avec des paramétrages de test ^^ De toute facon tu as les profiles maven pour packager ton appli avec une conf et la jouer en test avec une autre.