un des intérêts soulignés ici d’avoir des tests réellement unitaires est leur rapidité d’exécution.
Lorsqu’un test unitaire est cassé il est important de le savoir au plus vite, afin de corriger l’anomalie au plus tôt. En particulier lorsque l’on utilise un serveur d’intégration continue, si le build dépasse la dizaine de minutes ça peut devenir rapidement désagréable…

Dès que l’on introduit l’utilisation d’une base de données dans les tests, ils vont prendre plus de temps à s’exécuter (on peut peut-être utiliser une base de données en mémoire, comme hsqldb, mais ça n’élimine pas totalement le problème).

Il est donc recommandé de séparer ces tests des tests unitaires, en les plaçant par exemple dans un module dédié de tests d’intégration. Ce qui permet ensuite de ne les jouer que pour les nightly builds par exemple, ou seulement quelques fois par jour, et non à chaque modification du code.

Pour aller plus loin sur les tests qui dialoguent avec la base de données, il existe plusieurs outils:

- HSQLDB est une base de données 100% Java, qui dispose d’un mode « stockage en mémoire »
- DbUnit permet de replacer la base dans un état connu entre chaque test
- Unitils est une librairie qui facilite l’utilisation de DbUnit (entre autres) avec JUnit

Guillaume Carré (Xebia)

pour un projet qui est lié à une base de donnée, comment se passe la partie test avec la base de donnée ?
vous parlez de test d’integration…
pourriez vous en dire un peu plus?

Cordialement,
Mathieu