Stratégies de test modernes pour le développement d'applications IBM i: établir les bases de la qualité dans les environnements RPG et CL

Depuis des décennies, IBM i a acquis sa réputation de plateforme robuste. Pourtant, dans un environnement de développement actuel en constante évolution et axé sur le client, la stabilité ne suffit plus. Les applications doivent également être rapidement adaptables, sécurisées et résilientes, sans compromettre la qualité. Cette exigence impose de nouvelles pressions aux équipes de développement, notamment celles qui s'appuient encore sur des pratiques traditionnelles.

Un domaine où cette tension est particulièrement ressentie est celui des tests. D'aussi loin que je me souvienne, j'ai toujours observé que de nombreux clients sous-estimaient ou reléguaient les tests sérieux aux dernières étapes de la livraison. Cependant, les temps changent et les tests commencent à occuper une place centrale chez nombre de nos clients. Avec la modernisation des équipes IBM i, les tests ne sont plus un simple accessoire: ils sont devenus un élément essentiel de la santé et de la rapidité de livraison des logiciels.

DevOps, Agile et la quête de la qualité

L'adoption croissante, quoique plus lente que prévu, des pratiques Agile, DevOps et CI/CD, même au sein des environnements IBM i traditionnels, contribue à rehausser progressivement l'importance des tests. Ces méthodologies modernes visent à accélérer la livraison, mais exigent également une plus grande cohérence et des normes de qualité de code plus élevées.

Malheureusement, de nombreux services IBM i continuent de s'appuyer sur des tests manuels, des processus d'assurance qualité anecdotiques, voire des vérifications par l'utilisateur final. Ces approches sont lentes, sujettes aux erreurs et incapables de supporter des changements continus. Conséquences: des versions sujettes aux bugs, des régressions inattendues et des retards dans la livraison de valeur.

Dans le développement logiciel moderne, les tests unitaires constituent une exigence de base. Mais sur IBM i, notamment dans les environnements RPG et CL, les tests unitaires sont encore une pratique émergente. Les raisons sont compréhensibles: historiquement, la plateforme manquait de frameworks de test, et de nombreux programmes RPG sont étroitement couplés et difficiles à isoler pour les tests.

Mais les choses évoluent. Des outils de test légers pour RPG existent désormais. Plus important encore, un changement de mentalité s'opère: les développeurs IBM i commencent à adhérer à l'idée qu'un code testable est un code de meilleure qualité: plus facile à maintenir, plus facile à refactoriser et plus sûr à déployer.

Si c'est difficile à tester, c'est probablement difficile à maintenir.

Pourquoi les tests unitaires sont importants

Les tests unitaires offrent un filet de sécurité lors du refactoring, favorisent la prévention des régressions et améliorent l'intégration des nouveaux développeurs. À mesure que les entreprises modernisent leurs applications IBM i, les tests unitaires offrent un moyen pratique d'améliorer progressivement la fiabilité du code existant sans le réécrire entièrement.

Adopter le virage à gauche – avec des attentes réalistes

Le mouvement de « shift left » (changement de direction vers la gauche), qui touche l'ensemble du secteur et consiste à intégrer les tests (et la sécurité) plus tôt dans le cycle de développement, est largement considéré comme une bonne pratique. Mais cela a un coût. J'ai constaté, presque sans exception, que la responsabilité de l'assurance qualité incombe de plus en plus aux développeurs, qui doivent désormais écrire, exécuter et maintenir les tests en plus de fournir de nouvelles fonctionnalités.

Les dirigeants négligent souvent cette réalité. Sans investissement dans l'automatisation, cette évolution ne fait qu'augmenter la charge de travail des développeurs et créer des goulots d'étranglement. Les outils de test automatisés, les harnais de test et les pipelines sont essentiels pour optimiser les efforts de qualité sans ralentir la livraison.

Le message est clair: si vous vous déplacez vers la gauche, vous devez automatiser.

Là où l'automatisation a le plus grand impact

L'automatisation des tests ne signifie pas automatiser tous les tests possibles. Il s'agit plutôt d'automatiser systématiquement les tests les plus rentables:

• Tests unitaires: exécution automatique dans le cadre d'un processus de build ou d'intégration continue {color}
  * Tests de fumée: exécutés après le déploiement pour vérifier les fonctionnalités de base
• Tests de régression: détecter les problèmes introduits par les modifications de code

Les plateformes DevOps modernes et les outils de script (tels que Jenkins, GitHub Actions ou les solutions DevOps dédiées à IBM i comme Rocket DevOps) peuvent déclencher ces tests dans le cadre de votre pipeline de livraison. Associée au contrôle de version et à l'automatisation des builds, l'automatisation des tests constitue la pierre angulaire d'un processus de livraison résilient.

La culture compte: encourager la qualité dirigée par les développeurs

Adopter les tests sur IBM i n'est pas seulement un défi technique ; c'est souvent un défi culturel. De nombreuses équipes fonctionnent encore en silos, où l'assurance qualité est séparée du développement et où les tests sont réactifs plutôt que proactifs.

Pour surmonter cela:

• Encouragez les développeurs à s’approprier la qualité — pas seulement le code
• Inclure les objectifs de test dans la planification des sprints et les évaluations de performance
• Offrir une formation et du temps pour adopter de nouvelles pratiques de test
• Aligner les mesures de test (par exemple, la couverture du code, le taux de réussite des tests) avec les indicateurs clés de performance de l'entreprise

Un chemin réaliste vers l'adoption des tests sur IBM i

Pour les équipes IBM i débutantes, la transformation des tests peut paraître intimidante. Mais ce n'est pas forcément tout ou rien. Voici une voie réaliste:

1. Commencez avec un nouveau code: introduisez des tests unitaires pour tous les nouveaux programmes RPG ou programmes de service.
2. Ciblez les zones à haut risque: identifiez le code hérité qui change fréquemment ou provoque des problèmes et créez une couverture de test de base à cet endroit.
3. Automatisez les victoires faciles: les tests de fumée et la validation de la syntaxe peuvent souvent être automatisés avec un minimum d’effort.
4. Investissez dans l’outillage: qu’ils soient open source ou commerciaux, des outils prenant en charge les tests unitaires RPG, l’analyse de code et l’automatisation sont disponibles et valent l’investissement.

Réflexions finales: La confiance grâce aux tests

Les tests modernes ne visent pas la perfection, mais la création de boucles de rétroaction qui aident les équipes à détecter les problèmes en amont, à réduire le travail manuel et à déployer en toute confiance. Pour les équipes IBM i qui modernisent leurs pratiques de développement, des tests robustes constituent la première étape vers la résilience et l'agilité.