JUnit avec une BDD

Version imprimable

JUnit avec une BDD

Bonjour,

Comment je peux savoir qu'un assert a planté afin de faire un rollback des données que j'aurais insérer en base.
Code:

1 2 3 4 5 6 7 8 9 10 Utilisateur utilisateur = createUser(); assertFalse(utilisateurDAOImpl.existsUser(utilisateur, null)); //Insertion dans la base de données utilisateurDAOImpl.insertUser(utilisateur, null); assertTrue(utilisateurDAOImpl.existsUser(utilisateur, null)); //Suppression de l'utilisateur utilisateurDAOImpl.deleteUser(utilisateurDAOImpl.getUser(utilisateur.getIdWiki()).getId());
Pour illustrer : dans cet exemple, si un des asserts plantent, du coup l'utilisateur n'est pas supprimé de la base de données.

Merci

26/07/2007, 09h55
jpalcluc

bonjour,

il te faut travailler avec une "fausse" base de données et non la véritable base. C'est bien trop dangereux de travailler sur une véritable base.

Tu peux voir dbunit qui te fait décrire une BDD dans un fichier XML. La base est montée en mémoire à chaque test (ou à chaque classe de test, c'est selon ton appel dans le constructeur du test) afin d'avoir des tests indépendants. Ainsi, si un assert échoue, ta base n'est pas abimée car elle est détruite au tearDown et reconstruite au setUp suivant.
30/07/2007, 09h53
Llaur76

Ta solution serait une bonne alternative.
Mais le but restant de tester des méthodes pointant sur les "vraies" bases de données.
Je n'ai pas envie de dupliquer mes méthodes ou de rajouter un paramètre test pour mettre tel ou tel table dans ma requête.
Ma réponse va refléter la flemmardise de quelques informaticiens mais mes tests JUnit étant tous réalisés, la mise en place de DbUnit me parait un peu lourde.
Aurais tu une solution pour faire ce fameux rollback si un assert plante ?

Merci
30/07/2007, 10h09
xv-mnt

Les tests devant être indépendants, tu DOIS nettoyer la DB avant chaque test pour repartir d'un contexte "sain", peut importe que ton test échoue ou pas.

Sinon, tu ne peux jamais garantir qur ton test unitaire sera valide.

Donc, ce que tu peux faire c'est de surchager la classe TestCase pour que dans le setup() et/ou le teardown() tu nettoies ta DB.
30/07/2007, 10h31
jpalcluc

Bonjour,

je suis d'accord : les test doivent être indépendants, et dbUnit (qui n'est pas lourd à mettre en place) permet cela facilement sans rien casser.

par contre, attention : de quoi parle-t-on ici ?

dbUnit permet de faire des tests unitaires de ton code java d'accès aux données (qu'on appelle souvent la couche DAO). Le propos de cet outil n'est pas de tester l'accès à la base de données, mais le code.

ce que tu désires faire, c'est tester l'accès à la base de données : il s'agit là de tests d'intégration, et dbUnit n'est pas la solution. Là, tout dépend de la politique de ton enterprise : soi tu as accès à une base de dev ou tu peux faire ce que tu veux dessus (avec des scripts SQL pour tout nettoyer à la fin, mais berk), soi tu as accès à une base d'intégration et dans tous les cas tu dois faire des rollback en fin de transaction, car tu ne seras pas le seul à taper dessus. Pour faire ton rollback, tu peux le faire dans ton tearDown comme proposé ci-dessus, c'est à mon avis le plus propre. La méthode tearDown est appelée systématiquement, tu ne risques rien.

cela dit, rien ne t'empeche de faire les deux : des test unitaires (indispensables) et des tests d'intégration. on peut imaginer que tes sources de tests seront dans des dossiers distincs (par exemple unit-tests et integration-tests).
si tu utilises un outil de build en continu (continuum, luntbuild), les tests unitaires doivent êtres lancés à chaque commit et les tests d'intégration chaque jour (typiquement la nuit).
30/07/2007, 10h41
Llaur76

Je revenais justement ici pour clore le post, en effet en fouinant sur le net ce matin, j'ai trouvé cette fameuse méthode tearDown où je supprime mes données. Je ne sais pas si c'est très propre en tout cas ça répond parfaitement à mes attentes.

Petite précision, je n'ai pas relu mon post mais j'ai du mal m'exprimer, je ne teste pas la connection à ma base de données mais bien les méthodes contenues dans les DAO.

Merci à tous
30/07/2007, 10h43
jpalcluc

Citation:

Envoyé par Llaur76

je ne teste pas la connection à ma base de données mais bien les méthodes contenues dans les DAO

alors la solution est dbUnit, pas besoin de jouer avec tearDown en tapant sur une véritable instance de BDD : tu construits ton jeu de test dans un fichier XML, tu trifouilles les données, et ton code java est testé. Pense à bien découper tous tes cas et à rester unitaire.

bon courage pour la suite.