Pratiquer le test d’unités dans vos i-programmes

En tant que copropriétaire d’une société qui fournit des solutions de gestion du changement de logiciel (SCM, software change management) pour des systèmes IBM i, je sais à quel point le test du logiciel est important. Quand, voilà six ans environ, nous sommes passés au développement Java pour le frontal, nous avons été frappés par l’élégance, la simplicité et l’exhaustivité de la gestion de la qualité du code d’Eclipse. Dans la communauté Java, le style de coding ne souffre aucune ambiguïté. Tout le monde est d’accord sur la manière dont les programmes doivent être écrits. Et l’un des petits bijoux en matière de qualité du code est le test d’unités, qui peut aussi être appliqué au développement d’applications IBM i, comme nous le verrons ici.

Qu’est-ce que le test d’unités?

Le test d’unités est l’art de tester une unité de logiciel le plus indépendamment possible des autres parties du système. Une unité est un programme, une procédure, une commande, une zone de données, ou, plus généralement, tout ce que vous pouvez manipuler en externe pour juger de sa solidité. Un test classique consiste à voir comment un programme réagit à l’introduction d’un paramètre incorrect. Si un paramètre demande une décimale, comment le programme réagira-t-il à une saisie de texte ? Il pourrait : rejeter le paramètre et terminer, continuer avec une valeur par défaut et journaliser, ou tout simplement ne pas vérifier et compter sur la chance. J’entends déjà ceux qui estiment que cela ne se produira jamais dans des conditions d’exploitation normales et qu’un tel test n’est donc pas nécessaire. Peut-être, mais comme le dit Murphy : si cela peut arriver, cela se produira … et au pire moment.

Si vous avez créé une API ou un module d’I/O pour votre base de données clients, vous voulez avoir la certitude que ce programme fonctionne. Il doit être capable de créer un client, d’extraire des informations le concernant, de mettre à jour un ou plusieurs attributs et, finalement, de supprimer un client. Un tel programme est le candidat idéal pour un test d’unité. Chaque fois que vous préparez un changement de production, vous pouvez effectuer ce test d’unités, afin de savoir que, quoiqu’il se passe par ailleurs, votre API client fonctionnera comme prévu.

Malheureusement, nous n’avons pas eu ce genre de test d’unité de bas niveau pour le System i — du moins jusqu’à présent. Récemment, ma société, Remain Software, a lancé un projet de test d’unités, appelé IUnit, en réponse à une question sur Twitter sur la manière d’effectuer des tests d’unités sur un System i. Mais qu’en est-il des tests d’unités que nous connaissons pour Java/Eclipse/JUnit ? Ne pourrions-nous pas les appliquer au System i ? Bien sûr que si et je vais vous montrer comment.