Créé à la fin des années 90, JUnit est rapidement devenu le standard de facto pour le développement des tests unitaires en Java. Néanmoins, l’outil souffre d’un certain nombre de limitations obligeant les développeurs à mettre au point des contournements pas toujours très heureux. Fort de ce constat, un architecte Java a pris le taureau par les cornes en mettant au point un outil venant corriger ces problèmes. Nommé TestNG, ce framework ne se contente pas de cela puisqu’il apporte une nouvelle approche pour la réalisation de tests en Java. Présentation et prise en main de cet outil destiné aux applications nouvelle génération
Au départ, il y a un architecte Java français du nom de Cédric Beust qui petit à petit prend conscience des limites de JUnit début 2004. Pis encore, il s’aperçoit que celles-ci ont en fait été implémentées sciemment lors du design du framework. Le premier exemple mis en lumière apparaît lorsque l’on souhaite maintenir un état entre les différents tests contenus au sein d’une classe de tests JUnit. Par défaut, ce dernier ne le permet pas puisqu’il va ré-instancier la classe après l’exécution de chacune des méthodes de tests la composant. La garantie de l’indépendance du contexte d’exécution entre chacun des tests d’une classe étant l’argument mis en avant par les créateurs de JUnit pour justifier cette ré-instanciation systématique. Argument quelque peu fallacieux puisque la méthode setup invoquée entre chaque test doit permettre de garantir cette indépendance ! Pour Cédric Beust et plusieurs autres observateurs du monde Java, il paraît nécessaire de pouvoir conserver une connexion JDBC, un contexte applicatif Spring ou bien le résultat du parsing d’un gros fichier XML afin de minimiser la durée d’exécution des tests.

Sylvain Saurel