Améliorer la qualité des programmes avec les « Unit Testing»

Mon objectif est de démystifier certains concepts orientés objets qui font passer les développeurs iSeries pour des hommes de Néandertal, démontrer qu’on peut les appliquer aux langages L3G comme le RPG ou le Cobol et exécuter le tout sur un AS/400, iSeries.

Cet article propose l’application du concept de « Unit  Testing» dans le cas précis des programmes externes. N’incluant aucune astuce technique il s’adresse également aux débutants et j’espère toutefois qu’il surprendra les plus confirmés car il y a une réelle rupture dans la manière de réaliser des tests et surtout un gain temps. 
La démarche : dans un premier temps, j’ai considéré qu’on pouvait séparer le couple programme appelé-programme appelant. Il devient possible de tester le « programme appelé » hors de son contexte de production.

Les tests basiques

Le plus simple pour tester un programme externe est de créer un CLP et un DSPF spécifiques à ce module. Le DSPF permettant la saisie des paramètres, le CLP n’étant qu’un moyen d’appeler le module. C’est simple, facile et rapide à mettre en œuvre (Voir dans l’exemple, TUNIT20CL et TUNIT30CL).

Mais, il faut définir pour chaque cas de figure, les bons paramètres, vérifier visuellement les paramètres en retour et donc enchaîner tous les tests manuellement. Pourquoi ne pas automatiser ces tests en s’inspirant des unit testing ?