Intégrez le CT dans votre Pipeline CI/CD

Avec CodeChecker, il vous suffit d’un simple clic dans RDI lorsque vous utilisez la suite ARCAD for DevOps, ou il peut être installé de manière autonome avec un client Eclipse. Quelle que soit la méthode choisie, les fonctionnalités restent les mêmes, le serveur pouvant être exécuté sur IBM i ou Windows.

Avant d’aborder les tests unitaires, voici quelques points clés supplémentaires concernant CodeChecker :

• Il prend en charge plusieurs langages IBM i tels que RPG, COBOL, CL et SQL.
• Il est compatible avec les pipelines et l’automatisation.
• Il charge des règles préconfigurées pour vous aider à démarrer.

Je sais que la qualité du code ne fait pas partie de la définition stricte des tests, bien qu’elle soit cruciale pour garantir une base de code solide. Cependant, la vérification des violations de sécurité en fait partie, car leur impact sur la production peut être considérable.

2. Tests unitaires

L’outil ARCAD iUnit pour les tests unitaires s’inscrit une fois de plus dans la méthodologie « Fail Fast, Shift Left ». Cela permet à vos développeurs de tester les modules et les procédures sans avoir besoin de terminer l’ensemble du programme. Ainsi, que vous codiez en RPG, COBOL ou même en CL, iUnit vous couvre. Grâce à sa détection automatique des paramètres simples ou complexes en RPG, ses capacités de modélisation (mocking), et son héritage des fonctionnalités de JUnit, iUnit possède toutes les fonctionnalités nécessaires pour répondre à vos besoins.

Parmi les éléments qui peuvent être testés figurent les fonctions, les procédures, les programmes, les programmes de service ainsi que les procédures SQL. Toutes ces fonctionnalités sont accessibles directement depuis RDi, et bientôt, une intégration plus poussée sera disponible dans le plugin Skipper de la suite DevOps. Cette nouvelle fonctionnalité permettra d’accéder aux tests unitaires en un simple clic droit.

Avec les fonctionnalités héritées de JUnit, ARCAD propose une autre méthode pour inciter les nouveaux développeurs du monde Open System à découvrir le RPG et l’IBM i. Comme il est compatible avec JUnit, il peut également être intégré directement dans le pipeline d’automatisation avec Jenkins, si nécessaire. Personnellement, je pense que la capacité de tester les modules instantanément est le meilleur moyen d’obtenir des résultats rapidement.

3. Test de régression avec Verifier

Pour compléter la phase de test, nous avons les tests de régression. Comment s’assurer que les applications développées et testées précédemment continuent de fonctionner de la même manière après une modification ?

Ces tests sont généralement réalisés par l’équipe d’assurance qualité ou, tout aussi souvent, par toute personne disponible. Vous avez la possibilité de réaliser des tests manuels ou automatisés sur un seul scénario ou une seule opération, couvrant ainsi plusieurs domaines. La question est de savoir quel scénario exécuter.

Avec ARCAD Verifier, un référentiel de références croisées est constamment mis à jour pour déterminer le scénario à exécuter. Si vous modifiez le programme PGM001, tous les scénarios et campagnes associés à ce programme seront automatiquement identifiés ou sélectionnés pour être exécutés. Cette fonctionnalité seule peut vous faire gagner du temps, ce qui se traduit par des économies financières à long terme.

ARCAD Verifier gère à la fois les comparaisons 5250 et les comparaisons de fichiers spooled, ce qui est utile, mais il examine également la base de données DB2 sur IBM i pour identifier les différences au niveau des fichiers et des champs. Avec l’examen DB2 sur IBM i, des outils comme Selenium peuvent être utilisés pour vérifier que les données entrées et traitées au niveau de l’interface web correspondent à ce qui est attendu dans la base de données DB2 en backend.

Vous avez également la possibilité de comparer une entrée 5250 avec une entrée enregistrée par Selenium afin de repérer toute erreur dans le traitement de l’application. De plus, il teste également les différences au niveau de l’interface utilisateur.
Enfin, il prend en charge les traitements par lots et les tâches interactives. À mesure que le pipeline se rapproche du déploiement, les tests de régression deviennent la dernière étape du processus pour prévenir l’apparition de défauts dans la production, y compris la découverte de problèmes liés à un projet de modernisation.

4. Le mot de la fin : le test continu dans le processus CI/CD

Les principaux objectifs de l’intégration des tests continus dans le flux de travail CI/CD sont les suivants :

• « Shift left » pour détecter les problèmes le plus tôt possible.
• Passer d’un processus manuel à un processus automatisé pour garantir la cohérence, la vérifiabilité et la scalabilité.
• Favoriser un processus de développement agile.

Nous avons abordé trois domaines majeurs du pipeline de test, chacun étant couvert par une solution ARCAD. Le « bonus » ici est que ces produits peuvent s’intégrer à un pipeline ARCAD for DevOps existant ou être ajoutés à un pipeline de développement existant en tant qu’installations autonomes.
Si vous vous demandez par où commencer, la réponse est simple : quels sont vos besoins ? Il n’est pas nécessaire de suivre un ordre spécifique pour mettre en œuvre les mesures. Identifiez la zone problématique et nous pourrons vous aider à trouver une solution. Bonne phase de test !

Attendez, pas si vite ! Saviez-vous que vous pouvez également extraire des informations de ces outils pour les refléter dans un tableau de bord ? Cela peut parfois fournir une vue d’ensemble. Ci-dessous, vous trouverez quelques exemples de ce qui peut être extrait du tableau de bord ARCAD VSM associé à la suite d’outils de test :

Figure 2 – Verifier via Jenkins and Dashboard

Maintenant, n’hésitez pas à vous lancer et à tester encore et encore.