MagicTest : écrire des tests unitaires, naturellement
Par Grégory Levilain • 28 jan, 2010 • Catégorie: Java, Productivité, Qualité, Test, news •Voici une news qui a attiré mon attention : “MagicTest - an Automated Visual Approach for Testing“. Éliminer les assertions dans les tests unitaires est un concept séduisant. MagicTest réalise cela en instrumentant les classes de test et en se basant sur le résultat obtenu lors d’une exécution précédente du test, sous réserve que ce résultat ait été sauvegardé. Ainsi, pour consulter et sauvegarder les résultats, on dispose d’une console simplissime qui apporte une dimension visuelle plutôt agréable.
Console MagicTest
En supprimant les assertions, les tests sont plus rapidement codés et le traitement des exceptions, particulièrement, est habilement inhibé. Autre aspect attrayant expliqué dans cet article : un changement volontaire d’implémentation, ayant une répercussion sur le résultat des tests, n’implique pas nécessairement d’en modifier le code, comme cela aurait été le cas avec des assertions classiques. Ici, il suffit de valider/sauvegarder les nouveaux résultats obtenus après une simple consultation visuelle.
Sauvegarde de nouveaux résultats
Les tableaux produits par la console ne sont pas sans rappeler les “tables de décision” de Fitness, et bien que MagicTest n’a pas spécialement un caractère “collaboratif”, il pourrait bien constituer une alternative pour ceux qui n’apprécient pas la complexité de Fitness, notamment dans la façon de réaliser les associations entre le wiki et le code des tests.
Pour aller plus loin dans la découverte de cette approche, il faudrait avoir l’opportunité de tester MagicTest mais celui-ci n’est malheureusement pas encore disponible en téléchargement.
Grégory,
Je ne pense pas que MagicTest et Fitnesse puissent être substitués l’un à l’autre (donc que MagicTest puisse être une alternative à Fitnesse comme tu l’évoques), car ils ne sont pas utilisés pour la même chose ; si j’ai bien compris, MagicTest a pour vocation de faire gagner du temps dans la rédaction et la maintenance des tests unitaires mais on reste ici dans le cadre de tests unitaires. FitNesse n’est pas un outil facilitant le codage des tests unitaires c’est un Framework destiné à la rédaction des tests d’acceptance : les tests d’acceptance sont rédigés dans FitNesse (en fait un Wiki) dans un langage proche du langage métier, permettant de valider une “user story” ; ils sont rédigés en collaboration avec le product owner et les développeurs, ils sont la “propriété” du product owner (idéalement). Ils sont rédigés avant même le codage des tests unitaires … Il y a ensuite le code (fixture) qui sera appelé par le moteur Slim (en général on choisit Slim) suite à la lecture des pages du Wiki, ce code n’a rien à voir avec du test unitaire mais permet de faire le lien entre le Wiki et le code de l’application. Un test unitaire (même avec MagicTest) restera toujours essentiellement du code java à écrire, avec FitNesse on sépare la rédaction du test en langage métier (en formalisme Wiki) du code nécessaire à l’exécution du test d’acceptance.
Ca serait intéressant de relancer le rédacteur de l’article que tu mentionnes : cet article étant le dernier qu’il ait écrit (14/12/2009), et cela fait 2 mois qu’il indique être prêt à mettre les sources à disposition, pourtant rien n’est disponible à ce jour.
A+