Effectuer des tests

Voici un exemple de test concluant :

PGM
DLYJOB DLY(1)
ENDPGM

Un test significatif

Après ces quelques exemples simples, voyons un test significatif : celui de la figure 2 pour la commande SNDMSG. Celle-ci a pour objet d’envoyer un message à un autre utilisateur. Bien entendu, le message doit arriver intact et c’est ce que nous testons dans ce petit programme.

Exécuter tous les tests

Pour exécuter tous les tests, commencez par restaurer la bibliothèque IUNIT; puis appelez le programme @RUNALL comme ceci :

===> call iunit/@runall iunit

Après quelques secondes, vous recevrez ce message :

===> call iunit/@runall iunit
00003 tests ran. 00002 failed, 00001 good.

Le joblog contient l’information suivante (astuce : vous pourriez imprimer le joblog dans @TEARDOWN) :

4 > call iunit/@runall iunit
    @SETUP program called
    Boom.
    IUNIT/FAIL unit test failed. See previous message for details
    The text was not the same, see dump.
    IUNIT/TESTXMP unit test failed. See previous message for details
    End of file detected for file @RUNALL in QTEMP.
    @TEARDOWN program called
    00003 tests ran. 00002 failed, 00001 good.

Exécuter un test

Pour  exécuter un test, à partir de la bibliothèque IUNIT, appelez le programme @RUNONE comme ceci :

===> call iunit/@runone (iunit pass)

Vous recevrez ce message :

00001 tests ran. 00000 failed, 00001 good.

Conseils pour l’utilisation de IUnit

Voici quelques conseils et astuces pour tirer le meilleur parti de IUnit.

•    Créez une bibliothèque avec des tests d’unités pour chaque projet ou domaine. Laissez la bibliothèque IUnit en l’état, ou utilisez-la pour stocker des utilitaires génériques.
•    Faites une copie de @LOG, @TEARDOWN et @SETUP si vous devez les modifier et les mettre dans la bibliothèque de tests. Remain Software créera une commande pour faire cela plus tard — ou mieux encore, faites-en une et envoyez-la nous !
•    Créez des programmes sans paramètres et isolez-y le test.
•    Créez beaucoup de petits tests plutôt qu’un petit nombre de gros tests. Ils seront plus faciles à maintenir.
•    Documentez vos tests en interne. Cette documentation sera utile aux autres programmeurs parce qu’elle leur montrera comment un certain programme ou commande doit être utilisé.
•    S’il vous faut un programme utilitaire dans la bibliothèque de tests, faites précéder son nom de @ afin que IUnit ne l’appelle pas.
•    Soyez imaginatifs !

À vos marques, prêt, partez !

Les exemples de cet article vous ont montré comment effectuer des tests d’unités et comment démarrer votre propre test d’unités. Tout ce qui peut être considéré comme une unité peut être testé au moyen de IUnit. Chaque test doit être un programme afin qu’IUnit puisse facilement l’appeler. Cependant, à l’intérieur du programme, vous pouvez tester tout : des modules aux programmes de service.

J’ai décrit une entrée très simple pour une suite d’outils très puissante. Dans le monde entier, les tests d’unités sont reconnus à leur juste valeur. Non seulement ils vous donnent confiance en la qualité de vos programmes mais ils servent souvent d’exemples pour de nouveaux programmeurs, sur la manière d’utiliser une certaine unité. Consacrez une heure à essayer IUnit. Et si vous avez des questions, contactez-moi à wim.jongman@remainsoftware.com or sur Twitter @wimjongman.