Utilisation du framework de tests unitaires Rocket Software pour faciliter des tests plus intelligents des programmes du sous-système mainframe

Auteur supplémentaire pour cet article: Stephen Gennard

Introduction

Depuis la fin des années 1980 et l'avènement de SUNit, puis dans les années 1990 avec l'introduction de JUnit, l'utilisation des tests unitaires pris en charge par un framework de tests unitaires a connu une croissance rapide et est devenue une approche standard pour des millions de développeurs de logiciels au sein de la communauté du développement d'applications distribuées.

La grande division

Pour des raisons historiques de longue date, une limitation est perçue comme étant associée au code d'application écrit pour IBM.^® Sous-systèmes mainframe en ce qui concerne ces méthodes de test. Principalement écrit en COBOL et conçu pour fonctionner dans les sous-systèmes IBM.^® CICS^®, IMS et JES, le concept de tests unitaires de ces programmes d'application a traditionnellement été considéré comme un saut trop grand vers l'inconnu.

Chez Rocket, nous défendons depuis longtemps l'idée que ces applications et les langages de programmation utilisés pour les développer s'intègrent parfaitement au monde moderne du développement logiciel. Rocket^® Enterprise Developer (formerly part of Micro Focus) et Rocket^® Visual COBOL (formerly part of Micro Focus) fournissent le framework de tests unitaires depuis la version 2.3, sortie en 2015.

Avant la version 9.0 d' Enterprise Developer, un programme COBOL contenant à la fois de la logique métier et des instructions « EXEC SQL » et/ou « EXEC CICS » n'était pas un candidat idéal pour un test unitaire. C'est pourquoi la fonctionnalité MFUnit a été étendue afin de prendre en charge l'ignorance et la simulation des instructions EXEC CICS et SQL, simplifiant ainsi considérablement le passage d'un environnement de test à un environnement de test plus performant pour les programmes de sous-systèmes mainframe. Dans la dernière version, la 10.0, une prise en charge initiale des instructions « EXEC DLI » a été ajoutée.

Sans surprise, en raison de cette « grande fracture », peu d'écrits traitent actuellement de l'intérêt des tests unitaires pour le code d'application mainframe. Cependant, de nombreux articles, comme celui-ci, détaillent leur valeur. Si l'on considère un « élément de logiciel spécifique » comme un paragraphe ou une section de code COBOL, alors toutes les raisons évoquées s'appliquent également au code mainframe.

Comment peut-on l'utiliser ?

Avant d'entrer dans les détails, il est important de contextualiser l'utilisation de ces nouvelles fonctionnalités d'ignorance et de simulation EXEC SQL/CICS.

Son but est de « révéler » la logique COBOL d'un programme basé sur EXEC afin qu'il puisse être testé et ne doit pas être considéré comme une méthode pour tester dans son ensemble les applications basées sur CICS et/ou SQL.

Comment ça marche ?

Le préprocesseur Unit Test Seam (MFUPP) a été amélioré pour faciliter la création de tests unitaires autonomes contenant des instructions « EXEC CICS », « EXEC SQL » ou « EXEC DLI ».

Ces instructions EXEC peuvent être supprimées ou simulées en fonction des exigences du cas de test.

L'outil d'exécution des tests unitaires a également été amélioré pour faciliter le développement de ces styles de tests unitaires grâce à l'ajout de nouvelles options de génération de code disponibles via l'interface de ligne de commande.

Figure 1 - Préprocesseur de couture de test unitaire

Le préprocesseur Unit Test Seam (MFUPP) permet de manipuler le code sans modifier le code source original dans le seul but de créer un test unitaire.

Il a la capacité d'insérer des copybooks dans différentes divisions, de supprimer certaines instructions EXEC et d'insérer des instructions de rappel simulées.

Production de tests unitaires

Considérant un programme contenant des instructions SQL intégrées, il peut désormais être transformé en test unitaire par l'un ou l'autre des mécanismes suivants, voire les deux:

• Ignorer les instructions EXEC SQL
• Se moquer des instructions EXEC SQL

Il peut paraître étrange de disposer d'une fonctionnalité de préprocesseur de jonction qui supprime le code, mais elle s'avère très utile pour créer un test unitaire d'une section ou d'un paragraphe contenant du SQL intégré.

Si la section ou le paragraphe COBOL à tester ne contient qu'une seule instruction « EXEC SQL », il constitue un candidat idéal pour l'utilisation de la fonction de suppression des coutures du préprocesseur, car les valeurs mises à jour par l'instruction « EXEC SQL » peuvent être incluses dans le cas de test unitaire sans qu'il soit nécessaire d'utiliser une simulation.

Figure 2 - Paragraphe COBOL avec instruction SQL intégrée

Imagine un programme COBOL qui contient une instruction EXEC SQL FETCH pour obtenir une nouvelle ligne de données, puis effectue des calculs (logique métier) sur celle-ci.

Sans l'utilisation du préprocesseur de couture, il faudrait disposer d'une base de données déployée et utilisable pour les tests.

Ensuite, dans le cadre du test, un curseur doit être ouvert et prêt pour la récupération avant que le paragraphe puisse être testé.

Cela représente beaucoup de travail et de préparation pour tester une section ou un paragraphe. Figure 2 - Paragraphe COBOL avec instruction SQL intégrée

Figure 3 - Test unitaire ignorant l'instruction SQL

Grâce à la fonctionnalité de test unitaire autonome du préprocesseur Seam, il est possible de créer un cas de test qui sera intégré au programme.

Ceci est réalisé en écrivant le cas de test dans un fichier dont le nom préfixé est MFUPD_ . Cela permet de garantir l'accès à tous les champs du programme et d'exécuter un paragraphe PERFORM 50-FETCH-UPDATE .

Figure 4 - Test unitaire simulant l'instruction SQL.

L'exemple précédent de ScanEmployeeTable a maintenant évolué.

Il est désormais impossible de falsifier les valeurs issues de la requête SQL FETCH en supprimant simplement l'instruction EXEC SQL, car la première chose que fait le paragraphe « test » est d'initialiser la table EMP-TABLE, ce qui annule toute configuration de variable.

Il faut donc maintenant recourir à la moquerie.

Comme pour la prise en charge de la simulation de programmes fournie avant cette version, un point d'entrée doit être enregistré pour faire office de contrôleur. Cette opération s'effectue dans le point d'entrée des métadonnées et le nom du symbole est placé dans le champ MFU-MD-EXEC-CONTROLLER .

Ensuite, nous devons déclarer un point d'entrée pour gérer l'instruction SQL simulée ; dans cet exemple, c'est ici que seront configurées les instructions de déplacement nécessaires pour simuler cette instruction FETCH .

Dans cet exemple simple, tous les paramètres ne sont pas déclarés, car nous ne les utilisons pas.

La prise en charge des instructions « EXEC CICS » par le préprocesseur Unit Test Seam est conçue pour être familière, car ses fonctionnalités sont symétriques à celles fournies pour les instructions « EXEC SQL ».

Ignorer les instructions « EXEC CICS » et « EXEC DLI » est aussi simple que pour les instructions « EXEC SQL », et la simulation utilise le même mécanisme de rappel.

Figure 5 - Exemples d'ignorance des instructions EXEC DLI.

Contribuer à la rédaction des tests unitaires

Toute modernisation nécessite un investissement pour en tirer pleinement profit, mais tout outil de test doit aider au maximum le développeur à produire des cas de test. À cette fin, le framework MFUnit intègre une fonctionnalité de génération d'extraits de code permettant de simuler l'instruction EXEC du programme testé.

Figure 5 - Exemples d'identifiants uniques pour les instructions simulées.

Par défaut, le générateur d'extraits de code crée un extrait factice pour chaque instruction EXEC.

Chaque instruction simulée reçoit un identifiant unique ; cet identifiant peut être modifié en instrumentant le code avant l’instruction EXEC avec un commentaire.

Cela permet au générateur d'extraits de code de créer un code plus propre en limitant la génération de code à ces seuls identifiants personnalisés.

Figure 6 - Aide lorsque le programme simulé utilise une zone de virgules

Un programme CICS peut utiliser une zone COMMAREA, ce qui est normalement géré par le module ECM de CICS. Cependant, un cas de test peut nécessiter l'initialisation de cette zone et sa mise à disposition pour le remplissage. Le préprocesseur Seam injecte deux paragraphes supplémentaires pouvant être utilisés.

La section MFUPP--INIT-CICS alloue la COMMAREA et place la taille dans EIBCALEN.

Lorsque l'utilisation de la COMMAREA n'est plus nécessaire, la section MFUPP--END-CICS peut être utilisée.

Résumé

Le framework de tests unitaires, disponible avec Enterprise Developer, comporte deux nouvelles fonctionnalités dans le préprocesseur Seam.

La première consiste à supprimer ou à ignorer les commandes `EXEC SQL`, `EXEC CICS` et "EXEC DLI" qui révèlent la logique à tester sans avoir besoin de simulation.

La seconde fonctionnalité, la simulation d'instructions EXEC, permet d'utiliser des alternatives simplifiées aux instructions EXEC qui fournissent au programme juste assez de données pour permettre son test.

Grâce à cette prise en charge supplémentaire, les programmes des sous-systèmes mainframe peuvent être testés rapidement, car ni le sous-système lui-même, ni aucune donnée ne sont nécessaires. En fait, le code lui-même est le seul élément requis pour tester le code.

Pour voir cela en action, veuillez regarder cette vidéo .