Discussion :

[pamic]

Bonjour à tous,
J'ai une petite question : Quelle est la différence entre Cactus et JUnit ?
Est-ce complémentaire ?
Merci,

[coco62]

Cactus permet de réaliser des tests coté server(Servlets, EJBs, Tag Libs, Filters, ...).
Junit permet de tester du code java de type POJO(Plain Old Java Object), des classe Java simple quoi.

A+

[pamic]

Ok mais si j'utilise une base de données et que je veux faire des tests sur celles-ci, j'utilise JUnit ?

[clechenne]

Vas-tu utiliser des Datasources ?

[dlemoing]

La testabilité avec JUnit dépend directement de la dépendance que tu introduis dans ton code vis à vis du conteneur dans lequel tu vas executer ton appli. C'est notamment pour cela qu'il est si difficile de tester des EJB.
Rien ne t'interdit à priori de tester avec une base de données en arrière plan. Il faut juste faire en sorte que les tests soient reproductibles et qu'ils ne soient pas dépendant les uns des autres (un test ne doit pas s'executer avant un autre pour marcher et plusieurs executions successives des tests donnent le même résultat). Il est bon de prévoir un environnement de test et de faire un rollback sur chacun de tes tests.
Le mieux que je puisse te conseiller, c'est d'utiliser un framework du type Spring qui te fournira un mécanisme d'injection de dépendance et un tas de classes pour te faciliter les tests.

[pamic]

En faite ce que je voudrais savoir, c'est comment fonctionne les tests ? Genre on se connecte à une base de données, ça sera une base de données conçue uniquement pour les tests ou est-ce la vraie ?
Ensuite, on peut tester quoi sur cette base de données, la connection ? faire des tests sur des données ?
Je n'arrive pas à comprendre la philosophie des tests.

[toinou780]

Il faudrait déjà que tu définisses eaxtement ce que tu veux tester.

Est ce certaines méthodes du programme Java ou alors l'état de la base ?

Je crois plutôt que tu veux vérifier que ta base de données possèdent bien ce que tu veux.

Pour cela, tu peux utiliser dbUnit : http://dbunit.sourceforge.net/index.html

Il s'agit d'une extension de JUnit, les assertions vont comparer des tables.

Va sur le site si tu veux plus de détails sur le fonctionnement. En tous cas, moi je l'ai utilisé, ça marche bien.

++

Antoine

[pamic]

Donc en gros, si j'ai bien compris avec dbUnit : on peut se connecter à notre base de données, rajouter des tuples, et faire un test pour voir si ce tuple a bien été inséré ?

Je vois que l'on doit faire une base de données en XML ?? elle servira de test ?

Merci pour votre aide,

[dlemoing]

dbUnit te servira à tester ta base de données (je connais juste de nom, je n'ai jamais pratiqué).

Pour comprendre la philosophie des tests je te conseille ce paragraphe Testing practices.
On y explique rapidement l'idée de Test Driven Development (TDD) qui est à la base de la démarche XP (eXtreme Programming).

En résumé, écris tes tests avant de développer. Les tests doivent faire partie des développements et ne pas arriver après coup juste avant une livraison. Penser aux tests pendant tes développements rend ton architecture plus testable (à l'opposé on a des architectures "dé-testables", pas moyen de citer l'auteur de ce jeu de mot son blog étant en rade en ce moment), améliore souvent la qualité de ton code et permet de situer rapidement des sources de bugs ou de régressions.

[pamic]

Donc si j'ai bien compris avec DBUnit :
On a notre base de données, on se connecte à la base de données avec getConnection().
On la transforme en un fichier XML avec getDataSet().
Mais si on fait des insert ou des delete, ça ajoute ou supprime bien dans le fichier XML mais pas dans la base de données.
Et avec les fonctions getSetUpOperation() et getTearDownOperation(), il est possible de retrouver le fichier xml de base. getTearDownOperation() supprimera toutes les modifs effectuées sur ce fichier.

Sinon, on peut faire nous meme un fichier XML avec des données a l'interieur et faire des tests directement sur ce fichier.

J'ai bien compris ? ou je suis à coté de la plaque ? ou s'il y a des trucs qui ne sont pas exactes n'hésitez pas à me le dire.

Merci,

[pamic]

Autre question toujours en relation avec DBUnit :
Je vois dans les exemples qu'ils utilisent MySQL, est-ce que c'est compatible avec postgreSQL ?

[toinou780]

Pamic, je vais essayer de te répondre sur les principes. En revanche pour le code exact je te laisse regarder les exemples sur le site de DBUnit.

Je pense qu'il est souhaitable que tu te créé un environnement de test. Tes tests vont nécessiter que tu initializes un ensemble de tables, que tu les vides etc... donc fais attention à ça.

Donc si j'ai bien compris avec DBUnit :
On a notre base de données, on se connecte à la base de données avec getConnection().

->Si la doc le dit !

On la transforme en un fichier XML avec getDataSet().
Mais si on fait des insert ou des delete, ça ajoute ou supprime bien dans le fichier XML mais pas dans la base de données.

->Non ce n'est pas ça. Les scripts se font en XML comme tu l'as bien compris. Un DataSet est la représentation d'un ensemble de données compris dans une table.

-> Le process de tests est plutôt :

• - J'initialise ma table avec mes données (via DBUnit DataSet en XML)
  - Je fais tourner mon application (ou le bout de mon application qui modifie la table ou non)
  - Je récupère les données de la table (via DBUnit toujours)
  - Je compare les données obtenues avec les données attendues (comparaison de DataSet).

La comparaison de DataSet se fait via

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

	assertEquals(IDataSet expectedDataSet, IDataSet actualDataSet)

Et avec les fonctions getSetUpOperation() et getTearDownOperation(), il est possible de retrouver le fichier xml de base. getTearDownOperation() supprimera toutes les modifs effectuées sur ce fichier.

-> je ne sais plus exactement. Il me semble effectivement que la surcharge (ou non) de ces deux méthodes te permet de dire si tu veux
que tes tables soient réinitialisées à chaque fois ou non etc

Sinon, on peut faire nous meme un fichier XML avec des données a l'interieur et faire des tests directement sur ce fichier.

-> là je comprends pas ce que tu veux dire. DBunit compare lui-même les fichiers !

Sinon évidemment tu peux utiliser d'autres bases que MySQL sinon quel intérêt ????? il suffit qu'il y ait un driver JDBC.

++

Antoine

[pamic]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

assertEquals(IDataSet expectedDataSet, IDataSet actualDataSet)

Ce code permet de tester directement une table (ou une colonne...), DBUnit compare 2 fichiers XML en faite.

Je ne comprends pas : c'est nous qui éditons le fichier XML, quand on dit qu'on crée un dataSet, on crée un fichier XML ?

[toinou780]

Oui DBUnit compare les fichiers XML.

Oui : tu devras créer deux fichiers XML par tests :

- Un pour les données initiales qui seront contenues dans la table
- Un autre pour les données que tu attends.

Pour les créér, tu peux déjà te faire un petit prog qui récupère un DataSet et demander à DBUnit de te l'enregistrer dans un fichier.

Non, un DataSet n'est pas un fichier XML en tant que tel. Un DataSet est la représentation Objet du contenu d'une table. Et évidemment un DataSet peut être enregistré dans un fichier XML.

Regarde l'API : Classe org.dbunit.dataset.xml.XmlDataSet

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
static void 	write(IDataSet dataSet, java.io.OutputStream out)
          Write the specified dataset to the specified output stream as xml.

Faut que tu mettes les mains dans le cambouis.

++

Antoine