Les Unit Testing

On écrit un test pour confronter une réalisation à sa spécification. Le test définit un critère d’arrêt et permet de statuer sur le succès ou sur l’échec d’une vérification. … Le test permet de vérifier que la relation d’entrée / sortie donnée par la spécification est bel et bien réalisée. » (Source) . On trouvera aussi d’autres informations sur le site Wikibooks.

On retrouve en principe :

•    l’automatisation des tests
•    Une lecture simple des résultats (passed ou non)
•    Le codage de ces tests sur la partie publique des objets donc en dehors de l’applicatif, pour éviter les effets de bord.
•    Un jeu de test par objet, dans notre cas par programme.
•    les assertions cad des tests simples sur les valeurs en retour, assertTrue, assertFalse, assertEquals, assertNul (vrai, faux, null, .. qu’on peut remplacer facilement en RPG)

De cette définition, j’ai tiré les règles simples suivantes : l’automatisation des tests, la simplicité de la lecture des résultats (passed or not)  et la simplicité du re-jeu des tests.

Le programme

Il est basique, appel du programme, test des paramètres en retour, émission du message ok/pas ok, à la fin du programme message ok/erreurs détectées.

L’installation

Dézipper le fichier « example.zip », l’installation est résumée dans le fichier readme.me. Elle se limite  à un upload des sources par FTP, lancer INSTALL.CLP , lancer les programmes de test *TU.

Les exemples fournis

A titre d’exemple, voici 2 cas permettant de se faire une idée du principe et surtout de réaliser la simplicité du-rejeu de test. Dans PDM un call suivi de +F10+F10 et on obtient le résultat.

Exemple 1 : appel d’un programme de test de date au format aaaammjj. (CALL TUNIT20TU).

Exemple 2 : appel d’un programme de conversion euro en livre sterling avec des règles spécifiques d’arrondis (CALL TUNIT30TU).

Exemple de tests en erreur

.001.Ct date ok.passed
.002.Ct 31/06.passed
.003.Ct28/02/10.passed
.004.Ct29/02/10.passed
.005.Ct29/02/12** error
.006.Ct30/02/12** error
errors detected

Exemple de tests réussis

.001.Ct date ok.passed
.002.Ct 31/06.passed
.003.Ct28/02/10.passed
.004.Ct29/02/10.passed
.005.Ct29/02/12.passed
.006.Ct30/02/12.passed
tests passed

Les avantages de cette méthode

Ce qu’on ne voit pas dans les exemples, une démarche incrémentale

Au départ, le programme ne contient que deux, trois tests. Comme le re-jeu des tests est nul, rien n’empêche de tester de nouveaux cas. Il suffit de copier le pavé de test, modifier les paramètres en entrée, tester en retour une ou  plusieurs valeurs. On obtient facilement et de manière incrémentale une couverture complète de tests.

La démarche en maintenance

Si demain, vous trouvez un bug en production, vous rajoutez  le test dans l’unité de test. Vous rejouez le test pour bien vous assurer que le « programme appelé » est en défaut. Vous corrigez le « programme appelé ». Vous rejouez le jeu d’essai, c’est concluant. Vous venez de faire un test de non-régression complet et vous êtes sûr de ne pas avoir introduit de nouveaux bugs dans votre programme.

Autre problème en maintenance : se replonger dans un programme après quelques mois et surtout le re-tester complètement. Avec cette méthode vous êtes sûr de la qualité de vos tests, d’atteindre le même niveau de qualité que lors de la recette initiale, d’avoir balayé l’intégralité des tests nécessaires.

Optimisation de performances

Dernière piste que j’ai trouvée : la réécriture totale du « programme externe» pour des raisons de performances. C’est un cas où en RPG standard, la réécriture totale d’un programme va déstabiliser l’ensemble des applicatifs et vous obliger à des tests complets sur chaque applicatif. Avec le principe des unit testing et du codage des tests dans un programme externe, vous êtes sûr que le programme redéveloppé répondra aux même tests que l’ancien.

Evolutions possibles

Pour aller plus loin, en particulier tester les interactifs et les programmes d’édition, il faudrait qu’IBM « instrumente » le code pour permettre de tester la valeur de variables hors d’un programme.