Tester d’abord, coder ensuite

et continuer à effectuer les tests jusqu’à ce qu’il n’y ait plus d’erreur.

Les développeurs Java ont opté pour tester d’abord/coder ensuite, à l’aide d’un utilitaire simple appelé JUnit (voir junit.org).
WDSc et Eclipse ont intégré JUnit dans leurs IDE. Mais que doit faire un développeur RPG ? Il se trouve que la principale fonction de JUnit est assez facile à imiter en RPG. Pour l’essentiel, il suffit d’écrire un programme de test qui appelle votre API puis vérifie immédiatement si elle a bien fonctionné. Le plus difficile est d’ajouter des tests pour toutes les utilisations potentielles de cette API. Pour un excellent résumé des conseils de test en la matière, visitez pragmaticprogrammer.com/starter_kit/utj/ StandaloneSummary.pdf.

La figure 2 montre un module RPG appelé iUnit qui met en oeuvre trois procédures de test d’unité : assertEquals, assertTrue et fail (les prototypes correspondants se trouvent dans la figure 3). Les deux procédures assert prennent deux paramètres de type caractère d’une longueur maximale de 32 767 et un paramètre facultatif pour un message qui sera émis si l’assert échoue.

La figure 4 montre un module RPG qui teste les procédures iUnit en invoquant la procédure assertEquals avec divers types de données et assertTrue avec quelques instructions booléennes. Quand j’exécute iUnitTest à partir de la ligne de commande, j’obtiens la sortie suivante :

==> call dgg/iunittest
Optional text Expected
but was
Expected but was
Expected <7> but was <5.20>
Assertion Failed.
1 is not less than 0

A noter que les fonctions assert utilisent l’API send program message de l’iSeries pour vous informer des défaillances. Je vous conseille, après avoir accumulé une suite de tests d’unités, d’écrire un driver CL qui exécute tous les tests d’unités pour une application. Les responsables de la programmation pourraient même songer à automatiser l’exécution de leurs suites de test, en nocturne pendant la phase de développement, de manière à voir, chaque matin, quelles API ont échoué. (Comptez sur moi et sur mes copains – ou quiconque disposé à aider – pour améliorer iUnit afin de combler le fossé qui existe entre sa fonctionnalité et celles de jUnit.)