Blog#9

Au cours de mes missions, j’ai parfois besoin de tester et valider des applications Java massivement parallèles (comprenez : les développeurs ont utilisé plein de threads, et au bout d'un moment, plus personne ne sait qui appelle qui et dans quel ordre ;)).
Un petit tour sur le web m’a permis de découvrir quelques pépites et outils hautement recommandables sur le sujet.

Pour la théorie :

• Multithread unit tests with ConTest : un article brillant (et je pèse mes mots) sur la difficulté de tester des applications multithread, et comment ConTest peut y aider. A lire absolument !
• Testing concurrent software: une présentation JavaOne dédiée au sujet. Elle est largement didactique et permet de mieux cerner les enjeux et les difficultés des tests de programmes multithread.
• Pour les plus motivés, « Java Concurrency in practice », le livre de Brian Goetz (l'un des auteurs de la JSR 166 dédiée à la programmation concurrente) est une véritable mine d’information sur le sujet. On y apprend notamment que très peu de nos codes sont réellement thread-safe (même un simple "_counter++" ne l'est pas :-/!). Enfin, il a le bon gout d’être bien écrit, récent et relativement court (350 pages, hors annexes et index).

Pour la pratique, il existe quelques outils de tests Open-Source. Ils sont pour la plupart récents, donc perfectibles, mais apportent une vraie valeur ajoutée :

• IBM ConTest : cette librairie permet de simuler en accéléré les changements de contexte entre les différents threads de l’application. Pour cela, elle instrumente le bytecode pour y ajouter de manière aléatoire des éléments de synchronisations (yield principalement). Simple et très efficace, surtout pour les tests en "boite noire" (montée en charge).
• Multithreaded Test Case (MTC) : permet d’écrire des tests unitaires multithread, avec une API proche de JUnit. Elle gère la séquence des tests et permet de sérieuses économies de code à écrire (cf. cette page)
• Java PathFinder : Cette librairie, issue de la NASA, permet de tracer les changements de contexte ayant conduit à une exception, ce qui à l’usage est très pratique (plus besoin d’essayer d’imaginer ce qui a pu se passer, il suffit de le lire). Elle est particulièrement adaptée aux tests unitaires, mais par contre semble souffrir d’une réactivité quasi nulle de ses développeurs (la plupart des questions posées sur le forum de l’outil sont sans réponse).

Hope this helps !