> Tech > Tester d’abord, coder ensuite

Tester d’abord, coder ensuite

Tech - Par iTPro - Publié le 24 juin 2010
email

Les méthodologies Agile et Extreme Programming vous demandent d’écrire le code de test avant de mettre en oeuvre le code d’application. Mais comment faire ? C’est facile : vous devez écrirez les stubs pour votre API, écrire le RPG de test, tester l’API (qui échouera bien sûr), puis étoffer l’API

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

Vous écririez un programme RPG qui appelle votre API plusieurs fois (avec divers arguments destinés à tester profondément votre API) et, après chaque appel, vous utiliseriez l’une des fonctions assert pour vérifier les données renvoyées.

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.)

Téléchargez gratuitement cette ressource

Le Guide d’Orchestration du Parcours client

Le Guide d’Orchestration du Parcours client

Au-delà de la clarification des nouveaux concepts de gestion du parcours client, ce guide vous permettra de définir, créer et mettre œuvre une orchestration complète articulée autour des trois volets essentiels au succès de l’expérience client et de l’entreprise.

Tech - Par iTPro - Publié le 24 juin 2010