Par Olenka Van Schendel <\/h3>\n<\/div><\/div><\/div>Sur les syst\u00e8mes modernes et distribu\u00e9s, les tests unitaires sont sans doute l’\u00e9l\u00e9ment le plus efficace de votre strat\u00e9gie de test. Une batterie de tests unitaires bien con\u00e7us “impose” la qualit\u00e9 de votre application au fur et \u00e0 mesure de son d\u00e9veloppement – et id\u00e9alement m\u00eame avant.\u00a0 Les \u00e9l\u00e9ments des tests unitaires sont ensuite r\u00e9utilis\u00e9s en continu pendant toute la dur\u00e9e de vie de l’application afin de d\u00e9tecter toute r\u00e9gression dans le syst\u00e8me.<\/p>\n
Mais comment les tests unitaires peuvent-ils profiter aux applications existantes sur IBM i – et en particulier \u00e0 celles qui n’ont pas \u00e9t\u00e9 con\u00e7ues dans une optique “unitaire”, et o\u00f9 le code monolithique a toujours \u00e9t\u00e9 la norme ?<\/p>\n
Dans cet article, nous examinerons l’importance des tests unitaires en g\u00e9n\u00e9ral et \u00e9valuerons la pertinence de cette technique sur IBM i.<\/p>\n<\/div>
Sommaire<\/h2>\n\n- La qualit\u00e9 \u00e0 partir de la quantit\u00e9<\/a><\/li>\n
- Classification des d\u00e9fauts<\/a><\/li>\n
- “Shift Left” – d\u00e9tecter les erreurs le plus t\u00f4t possible<\/a><\/li>\n
- Un code “atomique” propre<\/a><\/li>\n
- Qu’en est-il de l’IBM i ?<\/a><\/li>\n
- L’importance de l’automatisation des tests sur IBM i<\/a><\/li>\n
- Garantir l’adoption des tests unitaires par les d\u00e9veloppeurs<\/a><\/li>\n
- La diff\u00e9rence avec Arcad i Unit<\/li>\n
- Conclusion<\/li>\n<\/ol>\n<\/div><\/div>\n
1. La qualit\u00e9 \u00e0 partir de la quantit\u00e9<\/strong><\/h2>\n![\"\"](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2020\/05\/Unit-Testing-Quality-from-Quantity-1-300x215.png\")
<\/p>\n
Les tests unitaires sont souvent n\u00e9glig\u00e9s au profit de techniques plus orient\u00e9es “business” comme les tests fonctionnels ou de bout en bout. Les tests unitaires prennent un temps pr\u00e9cieux aux d\u00e9veloppeurs<\/b>, surtout sur une base de code ancien comme IBM i qui n’est pas particuli\u00e8rement structur\u00e9 en “unit\u00e9s”. Alors comment un test unitaire par “bo\u00eete blanche”, sans connaissance des fonctionnalit\u00e9s r\u00e9elles de l’application, peut-il sauvegarder la qualit\u00e9 et la pr\u00e9cision de votre syst\u00e8me, sans parler de la r\u00e9duction de vos co\u00fbts de d\u00e9veloppement ?<\/p>\n
La solution r\u00e9side dans la quantit\u00e9 et la couverture des tests.<\/b><\/p>\n
Les tests unitaires impliquent la cr\u00e9ation d’une multitude de petits cas de tests tr\u00e8s simples. <\/b> Chaque test isole une section particuli\u00e8re du code (comme une proc\u00e9dure, un sous-programme, un bloc conditionnel), d\u00e9finissant le succ\u00e8s ou l’\u00e9chec en termes de valeurs attendues des param\u00e8tres de sortie pour une entr\u00e9e donn\u00e9e. L’ex\u00e9cution du test est ensuite stock\u00e9e comme “ligne de base”, et les tests ult\u00e9rieurs sont \u00e9valu\u00e9s par rapport \u00e0 ce r\u00e9sultat. Cela rend les tests unitaires tr\u00e8s efficaces pour d\u00e9tecter les r\u00e9gressions dans le syst\u00e8me. Ils peuvent \u00eatre r\u00e9utilis\u00e9s, regroup\u00e9s et ex\u00e9cut\u00e9s dans le cadre d’une suite \u00e0 tout moment, par exemple apr\u00e8s chaque build du syst\u00e8me, apr\u00e8s un changement d’environnement, ou avant qu’un composant particulier ne soit transf\u00e9r\u00e9 aux testeurs QA. Les tests unitaires cr\u00e9\u00e9s au d\u00e9but de la phase de d\u00e9veloppement peuvent \u00eatre utilis\u00e9s plus tard comme “smoke test” d’une application, afin de d\u00e9tecter les erreurs basiques et \u00e9viter de perdre du temps avec des tests plus sophistiqu\u00e9s.<\/p>\n<\/p>\n<\/div>\n2. Classification des d\u00e9fauts<\/strong><\/h2>\nEn effet, les classifications de d\u00e9fauts typiques r\u00e9v\u00e8lent que les d\u00e9fauts des logiciels peuvent \u00eatre attribu\u00e9s \u00e0 une grande vari\u00e9t\u00e9 de causes, notamment<\/b> :<\/p>\n\n- Erreurs dans la sp\u00e9cification, la conception et la mise en \u0153uvre du logiciel et du syst\u00e8me<\/li>\n
- Erreurs dans l’utilisation du syst\u00e8me<\/li>\n
- \nAnomalies dans l’environnement<\/div>\n<\/li>\n
- Dommages intentionnels<\/li>\n
- Cons\u00e9quences potentielles des erreurs ant\u00e9rieures<\/li>\n<\/ul>\n
Des enqu\u00eates r\u00e9centes ont montr\u00e9 que jusqu\u2019\u00e0 55 % des d\u00e9fauts sont dus \u00e0 des erreurs pr\u00e9sentes dans le cahier des charges.<\/b><\/p>\n
Il a \u00e9galement \u00e9t\u00e9 observ\u00e9 qu’environ 40 % du temps d’un testeur est consacr\u00e9 aux anomalies d’environnement<\/b>, ce qui a un impact important sur la qualit\u00e9 et la productivit\u00e9.<\/p>\n
Les nombreuses causes “p\u00e9riph\u00e9riques” des d\u00e9fauts signifient que les co\u00fbts globaux des tests peuvent \u00eatre consid\u00e9rablement r\u00e9duits en r\u00e9utilisant les cas de tests unitaires dans les “smoke tests”, avant d’entreprendre des tests de syst\u00e8mes co\u00fbteux \u00e0 grande \u00e9chelle.<\/p>\n
![\"\"](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2020\/05\/typical-defect-classification-1-300x242.png\")
<\/p>\n<\/div><\/div><\/div>
D\u00e9couvrez comment ARCAD for DevOps permet de contr\u00f4ler les co\u00fbts et d\u2019acc\u00e9l\u00e9rer les d\u00e9ploiements d\u2019applications dans des environnements technologiques h\u00e9t\u00e9rog\u00e8nes.<\/strong><\/p>\n<\/div>T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. “Shift Left” – d\u00e9tecter les erreurs le plus t\u00f4t possible<\/strong><\/h2>\nLes tests unitaires ne sont qu’une des nombreuses techniques des d\u00e9veloppeurs qui permettent de d\u00e9tecter les d\u00e9fauts le plus t\u00f4t possible dans le cycle de d\u00e9veloppement. Outre l’analyse statique du code, l’examen du code par les pairs, l’analyse de la couverture du code et d’autres pratiques, les tests unitaires permettent de d\u00e9tecter les erreurs le plus t\u00f4t possible,<\/b> au moment o\u00f9 elles sont le moins co\u00fbteuses.<\/p>\n
L’investissement en temps du d\u00e9veloppeur pour cr\u00e9er le test dans un premier temps peut \u00eatre compens\u00e9 par l’automatisation du processus de cr\u00e9ation. L’essentiel est de se concentrer sur des cas d’utilisation typiques qui affectent le comportement du syst\u00e8me. La combinaison de “happy path” et de “edge cases” rend les tests unitaires encore plus efficaces.<\/p>\n
Utilis\u00e9s en continu dans un cycle CI\/CD, les tests unitaires permettent de d\u00e9terminer pr\u00e9cis\u00e9ment dans quelles lignes de code se trouve le d\u00e9faut<\/b>. Les bugs sont corrig\u00e9s avant m\u00eame qu’ils ne quittent les mains du d\u00e9veloppeur !<\/p>\n<\/p>\n<\/div>\n4. Un code \u2018atomique\u2019 propre<\/strong><\/h2>\nPlus de 90 % des co\u00fbts de d\u00e9veloppement de logiciels sont consacr\u00e9s \u00e0 la maintenance des syst\u00e8mes existants<\/b>. La cr\u00e9ation de tests unitaires au fur et \u00e0 mesure que vous d\u00e9veloppez du code am\u00e9liore la conception du code et le rend plus facile \u00e0 comprendre par les \u00e9quipes de d\u00e9veloppement futures. En plus d’\u00eatre plus fiable, le code test\u00e9 \u00e0 l’unit\u00e9 est plus simple, plus modulaire et donc plus facilement r\u00e9utilisable. Cela permet de r\u00e9duire la dette technique et de diminuer les co\u00fbts de d\u00e9veloppement \u00e0 long terme.<\/p>\n
Dans sa forme extr\u00eame, le “Test Driven Development” apporte une clart\u00e9 suppl\u00e9mentaire m\u00eame lors de la d\u00e9finition des pr\u00e9requis en cr\u00e9ant des tests avant le code lui-m\u00eame.<\/p>\n<\/p>\n
<\/div>\n5. Qu’en est-il de l’IBM i ?<\/strong><\/h2>\nLes applications IBM i modernes con\u00e7ues avec une architecture ILE s\u00e9parent d\u00e9j\u00e0 les r\u00e8gles de gestion, la persistance des donn\u00e9es et l’interface utilisateur en modules ou fonctions distincts, ce qui facilite grandement l’automatisation des tests unitaires. Les points d’entr\u00e9e et de sortie d’un module sont clairs, de sorte qu’il est relativement facile de d\u00e9finir un \u00e9tat “r\u00e9ussite\/\u00e9chec”.<\/p>\n
Cependant, de nombreuses applications sur IBM i contiennent encore des sections de code source qui ont \u00e9t\u00e9 d\u00e9velopp\u00e9es il y a 40 ans et qui sont “trop importantes pour \u00eatre touch\u00e9es”. Cela cr\u00e9e une situation tr\u00e8s pr\u00e9caire dans laquelle le risque et le co\u00fbt de la refonte du code monolithique ou spaghetti en unit\u00e9s ou modules sont tr\u00e8s \u00e9lev\u00e9s. Oui, le prix \u00e0 payer pour ne rien faire doit \u00eatre d\u00e9pass\u00e9 par une approche plus agile. Heureusement, les tests unitaires cr\u00e9ent le filet de s\u00e9curit\u00e9 dont vous avez besoin lorsque vous modularisez votre code existant. En g\u00e9n\u00e9rant et en relan\u00e7ant des tests unitaires sur des applications ” back-end ” au fur et \u00e0 mesure que vous les modifiez, vous vous assurez que les d\u00e9ploiements pr\u00e9c\u00e9dents fonctionnent toujours lorsqu’ils sont combin\u00e9s \u00e0 de nouvelles fonctionnalit\u00e9s.<\/p>\n
Ce type de technique de “Test Driven Maintenance” (TDM) permet d’effectuer des tests unitaires \u00e0 la demande et par lots,<\/b> comme une sorte de syst\u00e8me d’alerte pr\u00e9coce pour emp\u00eacher l’apparition de r\u00e9gressions lorsque vous “d\u00e9m\u00ealez” votre ancien code.<\/p>\n
Pour \u00eatre pleinement adopt\u00e9e par les d\u00e9veloppeurs, toute fonctionnalit\u00e9 de test unitaire sur IBM i doit \u00eatre int\u00e9gr\u00e9e dans l’environnement de d\u00e9veloppement RDi, et aussi avec des outils standards tels que Jenkins et JUnit pour encourager le partage des outils entre les \u00e9quipes multi-technologiques.<\/b> Les meilleures solutions de tests unitaires sur IBM i peuvent automatiser \u00e0 la fois la cr\u00e9ation et l’ex\u00e9cution des cas de test, en utilisant la technologie d’analyse syntaxique pour rechercher les param\u00e8tres et leurs types de donn\u00e9es et identifier rapidement toutes les entr\u00e9es et sorties du programme test\u00e9. La connaissance des r\u00e9f\u00e9rences crois\u00e9es et des d\u00e9pendances permet \u00e9galement de g\u00e9rer les cas de test et de r\u00e9utiliser les cas entre les versions.<\/p>\n<\/p>\n<\/div>\n6. L’importance de l’automatisation des tests sur IBM i<\/strong><\/h2>\nIl existe encore quelques cas extr\u00eames o\u00f9 les applications IBM i ne peuvent pas \u00eatre facilement remani\u00e9es et o\u00f9 le co\u00fbt\/temps de restructuration du code est prohibitif.<\/p>\n
Dans ce cas, l’automatisation des tests fonctionnels est la meilleure option. Les cas de test sont cr\u00e9\u00e9s automatiquement lorsque les utilisateurs ex\u00e9cutent les fonctions de l’application \u00e0 partir de l’interface utilisateur standard. Contrairement aux tests unitaires o\u00f9 l’environnement de donn\u00e9es sous-jacent est dynamique, les donn\u00e9es de test fonctionnel sont statiques et restaur\u00e9es avant chaque ex\u00e9cution de test afin de d\u00e9tecter les r\u00e9gressions par simple comparaison des donn\u00e9es, sortie spool et interface utilisateur. Il n’y a pas de notion de succ\u00e8s ou d’\u00e9chec, seulement des diff\u00e9rences<\/em>.<\/p>\n![\"\"](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2020\/05\/test-automation-1-1024x435.png\")
<\/p>\n
Bien s\u00fbr, une strat\u00e9gie de test optimale combine \u00e0 la fois une automatisation des tests unitaires et des tests fonctionnels pour minimiser le temps moyen de r\u00e9paration (MTTR) des d\u00e9fauts dans leur ensemble. La r\u00e9utilisation et le partage des cas de test \u00e9vitent une perte de temps co\u00fbteuse pour le d\u00e9veloppeur et font des tests une activit\u00e9 continue, partie int\u00e9grante du cycle global CI\/CD.<\/p>\n<\/p>\n
<\/div>\n7. Garantir l’adoption des tests unitaires par les d\u00e9veloppeurs<\/strong><\/h2>\nEn conclusion, nous avons vu que les tests unitaires facilitent un style de test \u00ab bottom-up \u00bb, en validant les parties individuelles d’un programme avant de tester la “somme de ses parties” <\/b>– une approche qui anticipe les d\u00e9fauts restants et r\u00e9duit l’effort des tests d’int\u00e9gration ult\u00e9rieurs.<\/p>\n
Les tests unitaires agissent comme une sorte de “documentation vivante” du syst\u00e8me, permettant une compr\u00e9hension rapide de l’interface d’une unit\u00e9. Dans le cas d’un \u00ab Test Driven Development \u00bb, ils peuvent m\u00eame remplacer une sp\u00e9cification d\u00e9taill\u00e9e.<\/p>\n
Cependant, les tests unitaires doivent \u00eatre effectu\u00e9s en parall\u00e8le avec d’autres formes de tests, car ils ne permettent pas de d\u00e9tecter les erreurs au niveau du syst\u00e8me ou les erreurs fonctionnelles, ni les aspects non fonctionnels tels que les performances.<\/p>\n
Le principal d\u00e9fi des tests unitaires est la cr\u00e9ation de tests r\u00e9alistes et utiles<\/b>, afin d’\u00e9tablir les conditions initiales pertinentes qui refl\u00e8tent l’ex\u00e9cution normale d’une application. Plus important encore, les tests unitaires doivent \u00eatre maintenus en parall\u00e8le avec le processus de changement d’application lui-m\u00eame, afin de garantir que les tests impact\u00e9s soient maintenus \u00e0 jour et ex\u00e9cut\u00e9s pour chaque changement de code d\u00e9pendant. Pour faciliter la maintenance des tests unitaires, il doit \u00eatre facile de r\u00e9-identifier les nouveaux champs d’entr\u00e9e et de sortie \u00e0 mesure que l’application \u00e9volue.<\/b> Sinon, les tests unitaires peuvent devenir aussi bogu\u00e9s que le code qu’ils sont cens\u00e9s tester !<\/p>\n
Pour surmonter ces difficult\u00e9s, les tests unitaires doivent \u00eatre hautement automatis\u00e9s et faire partie int\u00e9grante du cycle de livraison continu :<\/b><\/p>\n\n- D\u00e9tection automatique des entr\u00e9es et des sorties pour automatiser la cr\u00e9ation de tests r\u00e9alistes\/utiles<\/li>\n
- Int\u00e9gration des tests unitaires dans le processus de contr\u00f4le de version<\/li>\n
- Auto-ex\u00e9cutions des tests en tant que partie continue du flux CI\/CD<\/li>\n
- R\u00e9utilisation des actifs des tests unitaires pour chaque changement de programme<\/li>\n
- Maintenance\/mise \u00e0 jour des tests unitaires en fonction des d\u00e9pendances<\/li>\n<\/ul>\n
En r\u00e9sum\u00e9, les essais unitaires sont tr\u00e8s b\u00e9n\u00e9fiques mais imposent une certaine rigueur, n\u00e9cessitant une automatisation maximale pour une adoption \u00e0 long terme !<\/p>\n
8. La diff\u00e9rence avec Arcad i unit<\/strong><\/h2>\nARCAD iUnit<\/a> a \u00e9t\u00e9 con\u00e7u pour maximiser l’automatisation tout au long du processus de test unitaire sur IBM i. En tant que tel, il peut m\u00eame \u00eatre utilis\u00e9 par des d\u00e9veloppeurs qui ont peu ou pas de connaissances de l’application \u00e0 tester.<\/p>\nTout ce dont ARCAD iUnit a besoin pour commencer \u00e0 travailler est un nom de biblioth\u00e8que. Il en d\u00e9coule un r\u00e9f\u00e9rentiel de connaissances sur les objets contenus dans la biblioth\u00e8que, utilis\u00e9 pour aider le d\u00e9veloppeur \u00e0 chaque \u00e9tape du processus.<\/p>\n
Une fois qu’ARCAD iUnit a analys\u00e9 le contenu de la biblioth\u00e8que, l’outil guide le d\u00e9veloppeur dans la cr\u00e9ation et l’ex\u00e9cution des tests \u00e0 partir d’une interface graphique facile \u00e0 utiliser. Toutes les t\u00e2ches les plus fastidieuses sont enti\u00e8rement automatis\u00e9es, telles que :<\/b><\/p>\n\n- l’identification de toutes les proc\u00e9dures d’un programme et de leurs param\u00e8tres d’entr\u00e9e\/sortie<\/li>\n
- la d\u00e9finition des r\u00e9sultats attendus<\/li>\n
- obtention\/r\u00e9glage de valeurs<\/li>\n
- marquage\/suivi des variables<\/li>\n
- ex\u00e9cution des tests – individuellement ou en tant que suite<\/li>\n
- exportation de tests vers JUnit<\/li>\n
- ‘mocking’ de base de donn\u00e9es, pour injecter des donn\u00e9es dans une table avant l’ex\u00e9cution du test<\/li>\n
- ‘mocking’ d’un programme, pour changer le comportement par d\u00e9faut du programme<\/li>\n
- ex\u00e9cution de projet “libre”, pour g\u00e9rer les programmes manquants<\/li>\n
- int\u00e9gration avec plusieurs outils d’automatisation : Jenkins, Azure Pipelines, CloudBees, GitLab CI…<\/li>\n<\/ul>\n
L’introduction de ce niveau d’automatisation fait avancer le d\u00e9veloppement d’applications IBM i dans le monde DevOps “continu” qui est caract\u00e9ristique sur les syst\u00e8mes distribu\u00e9s – avec tous les avantages que cela apporte en termes de fiabilit\u00e9 de l’application, de retour sur investissement, d’\u00e9limination de la dette technique ou encore de continuit\u00e9 de l’activit\u00e9 pour en nommer quelques-uns.<\/p>\n
9. Conclusion<\/strong><\/h2>\nEn bref, les tests unitaires sont un maillon indispensable et souvent manquant du d\u00e9veloppement logiciel sur IBM i.<\/p>\n
Les tests unitaires automatis\u00e9s peuvent rendre un pipeline DevSecOps sur IBM i v\u00e9ritablement continu<\/b> – avec des avantages mesurables en termes de qualit\u00e9, de vitesse et de co\u00fbt.<\/p>\n
Pourtant, l’adoption des tests unitaires et le taux de retour d\u00e9pendent du degr\u00e9 d’automatisation offert par l’outil de test unitaire. Pour obtenir un portail de qualit\u00e9 s\u00e9curis\u00e9, seuls les outils capables de d\u00e9charger TOUTES les t\u00e2ches de cr\u00e9ation de tests de routine du d\u00e9veloppeur avec suffisamment de flexibilit\u00e9 pour s’adapter \u00e0 un environnement changeant, seront adopt\u00e9s \u00e0 long terme. En ce qui concerne l’IBM i, ARCAD iUnit<\/a> apporte un niveau d’automatisation sans pr\u00e9c\u00e9dent et un ROI prouv\u00e9, quelle que soit la variante de langage utilis\u00e9e.<\/p>\n<\/div><\/div><\/div>
Sur les syst\u00e8mes modernes et distribu\u00e9s, les tests unitaires sont sans doute l’\u00e9l\u00e9ment le plus efficace de votre strat\u00e9gie de test. Une batterie de tests unitaires bien con\u00e7us “impose” la qualit\u00e9 de votre application au fur et \u00e0 mesure de son d\u00e9veloppement – et id\u00e9alement m\u00eame avant.\u00a0 Les \u00e9l\u00e9ments des tests unitaires sont ensuite r\u00e9utilis\u00e9s en continu pendant toute la dur\u00e9e de vie de l’application afin de d\u00e9tecter toute r\u00e9gression dans le syst\u00e8me.<\/p>\n
Mais comment les tests unitaires peuvent-ils profiter aux applications existantes sur IBM i – et en particulier \u00e0 celles qui n’ont pas \u00e9t\u00e9 con\u00e7ues dans une optique “unitaire”, et o\u00f9 le code monolithique a toujours \u00e9t\u00e9 la norme ?<\/p>\n
Dans cet article, nous examinerons l’importance des tests unitaires en g\u00e9n\u00e9ral et \u00e9valuerons la pertinence de cette technique sur IBM i.<\/p>\n<\/div>
Sommaire<\/h2>\n\n- La qualit\u00e9 \u00e0 partir de la quantit\u00e9<\/a><\/li>\n
- Classification des d\u00e9fauts<\/a><\/li>\n
- “Shift Left” – d\u00e9tecter les erreurs le plus t\u00f4t possible<\/a><\/li>\n
- Un code “atomique” propre<\/a><\/li>\n
- Qu’en est-il de l’IBM i ?<\/a><\/li>\n
- L’importance de l’automatisation des tests sur IBM i<\/a><\/li>\n
- Garantir l’adoption des tests unitaires par les d\u00e9veloppeurs<\/a><\/li>\n
- La diff\u00e9rence avec Arcad i Unit<\/li>\n
- Conclusion<\/li>\n<\/ol>\n<\/div><\/div>\n
1. La qualit\u00e9 \u00e0 partir de la quantit\u00e9<\/strong><\/h2>\n<\/p>\n
Les tests unitaires sont souvent n\u00e9glig\u00e9s au profit de techniques plus orient\u00e9es “business” comme les tests fonctionnels ou de bout en bout. Les tests unitaires prennent un temps pr\u00e9cieux aux d\u00e9veloppeurs<\/b>, surtout sur une base de code ancien comme IBM i qui n’est pas particuli\u00e8rement structur\u00e9 en “unit\u00e9s”. Alors comment un test unitaire par “bo\u00eete blanche”, sans connaissance des fonctionnalit\u00e9s r\u00e9elles de l’application, peut-il sauvegarder la qualit\u00e9 et la pr\u00e9cision de votre syst\u00e8me, sans parler de la r\u00e9duction de vos co\u00fbts de d\u00e9veloppement ?<\/p>\n
La solution r\u00e9side dans la quantit\u00e9 et la couverture des tests.<\/b><\/p>\n
Les tests unitaires impliquent la cr\u00e9ation d’une multitude de petits cas de tests tr\u00e8s simples. <\/b> Chaque test isole une section particuli\u00e8re du code (comme une proc\u00e9dure, un sous-programme, un bloc conditionnel), d\u00e9finissant le succ\u00e8s ou l’\u00e9chec en termes de valeurs attendues des param\u00e8tres de sortie pour une entr\u00e9e donn\u00e9e. L’ex\u00e9cution du test est ensuite stock\u00e9e comme “ligne de base”, et les tests ult\u00e9rieurs sont \u00e9valu\u00e9s par rapport \u00e0 ce r\u00e9sultat. Cela rend les tests unitaires tr\u00e8s efficaces pour d\u00e9tecter les r\u00e9gressions dans le syst\u00e8me. Ils peuvent \u00eatre r\u00e9utilis\u00e9s, regroup\u00e9s et ex\u00e9cut\u00e9s dans le cadre d’une suite \u00e0 tout moment, par exemple apr\u00e8s chaque build du syst\u00e8me, apr\u00e8s un changement d’environnement, ou avant qu’un composant particulier ne soit transf\u00e9r\u00e9 aux testeurs QA. Les tests unitaires cr\u00e9\u00e9s au d\u00e9but de la phase de d\u00e9veloppement peuvent \u00eatre utilis\u00e9s plus tard comme “smoke test” d’une application, afin de d\u00e9tecter les erreurs basiques et \u00e9viter de perdre du temps avec des tests plus sophistiqu\u00e9s.<\/p>\n<\/p>\n<\/div>\n2. Classification des d\u00e9fauts<\/strong><\/h2>\nEn effet, les classifications de d\u00e9fauts typiques r\u00e9v\u00e8lent que les d\u00e9fauts des logiciels peuvent \u00eatre attribu\u00e9s \u00e0 une grande vari\u00e9t\u00e9 de causes, notamment<\/b> :<\/p>\n\n- Erreurs dans la sp\u00e9cification, la conception et la mise en \u0153uvre du logiciel et du syst\u00e8me<\/li>\n
- Erreurs dans l’utilisation du syst\u00e8me<\/li>\n
- \nAnomalies dans l’environnement<\/div>\n<\/li>\n
- Dommages intentionnels<\/li>\n
- Cons\u00e9quences potentielles des erreurs ant\u00e9rieures<\/li>\n<\/ul>\n
Des enqu\u00eates r\u00e9centes ont montr\u00e9 que jusqu\u2019\u00e0 55 % des d\u00e9fauts sont dus \u00e0 des erreurs pr\u00e9sentes dans le cahier des charges.<\/b><\/p>\n
Il a \u00e9galement \u00e9t\u00e9 observ\u00e9 qu’environ 40 % du temps d’un testeur est consacr\u00e9 aux anomalies d’environnement<\/b>, ce qui a un impact important sur la qualit\u00e9 et la productivit\u00e9.<\/p>\n
Les nombreuses causes “p\u00e9riph\u00e9riques” des d\u00e9fauts signifient que les co\u00fbts globaux des tests peuvent \u00eatre consid\u00e9rablement r\u00e9duits en r\u00e9utilisant les cas de tests unitaires dans les “smoke tests”, avant d’entreprendre des tests de syst\u00e8mes co\u00fbteux \u00e0 grande \u00e9chelle.<\/p>\n
<\/p>\n<\/div><\/div><\/div>
D\u00e9couvrez comment ARCAD for DevOps permet de contr\u00f4ler les co\u00fbts et d\u2019acc\u00e9l\u00e9rer les d\u00e9ploiements d\u2019applications dans des environnements technologiques h\u00e9t\u00e9rog\u00e8nes.<\/strong><\/p>\n<\/div>T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. “Shift Left” – d\u00e9tecter les erreurs le plus t\u00f4t possible<\/strong><\/h2>\nLes tests unitaires ne sont qu’une des nombreuses techniques des d\u00e9veloppeurs qui permettent de d\u00e9tecter les d\u00e9fauts le plus t\u00f4t possible dans le cycle de d\u00e9veloppement. Outre l’analyse statique du code, l’examen du code par les pairs, l’analyse de la couverture du code et d’autres pratiques, les tests unitaires permettent de d\u00e9tecter les erreurs le plus t\u00f4t possible,<\/b> au moment o\u00f9 elles sont le moins co\u00fbteuses.<\/p>\n
L’investissement en temps du d\u00e9veloppeur pour cr\u00e9er le test dans un premier temps peut \u00eatre compens\u00e9 par l’automatisation du processus de cr\u00e9ation. L’essentiel est de se concentrer sur des cas d’utilisation typiques qui affectent le comportement du syst\u00e8me. La combinaison de “happy path” et de “edge cases” rend les tests unitaires encore plus efficaces.<\/p>\n
Utilis\u00e9s en continu dans un cycle CI\/CD, les tests unitaires permettent de d\u00e9terminer pr\u00e9cis\u00e9ment dans quelles lignes de code se trouve le d\u00e9faut<\/b>. Les bugs sont corrig\u00e9s avant m\u00eame qu’ils ne quittent les mains du d\u00e9veloppeur !<\/p>\n<\/p>\n<\/div>\n4. Un code \u2018atomique\u2019 propre<\/strong><\/h2>\nPlus de 90 % des co\u00fbts de d\u00e9veloppement de logiciels sont consacr\u00e9s \u00e0 la maintenance des syst\u00e8mes existants<\/b>. La cr\u00e9ation de tests unitaires au fur et \u00e0 mesure que vous d\u00e9veloppez du code am\u00e9liore la conception du code et le rend plus facile \u00e0 comprendre par les \u00e9quipes de d\u00e9veloppement futures. En plus d’\u00eatre plus fiable, le code test\u00e9 \u00e0 l’unit\u00e9 est plus simple, plus modulaire et donc plus facilement r\u00e9utilisable. Cela permet de r\u00e9duire la dette technique et de diminuer les co\u00fbts de d\u00e9veloppement \u00e0 long terme.<\/p>\n
Dans sa forme extr\u00eame, le “Test Driven Development” apporte une clart\u00e9 suppl\u00e9mentaire m\u00eame lors de la d\u00e9finition des pr\u00e9requis en cr\u00e9ant des tests avant le code lui-m\u00eame.<\/p>\n<\/p>\n
<\/div>\n5. Qu’en est-il de l’IBM i ?<\/strong><\/h2>\nLes applications IBM i modernes con\u00e7ues avec une architecture ILE s\u00e9parent d\u00e9j\u00e0 les r\u00e8gles de gestion, la persistance des donn\u00e9es et l’interface utilisateur en modules ou fonctions distincts, ce qui facilite grandement l’automatisation des tests unitaires. Les points d’entr\u00e9e et de sortie d’un module sont clairs, de sorte qu’il est relativement facile de d\u00e9finir un \u00e9tat “r\u00e9ussite\/\u00e9chec”.<\/p>\n
Cependant, de nombreuses applications sur IBM i contiennent encore des sections de code source qui ont \u00e9t\u00e9 d\u00e9velopp\u00e9es il y a 40 ans et qui sont “trop importantes pour \u00eatre touch\u00e9es”. Cela cr\u00e9e une situation tr\u00e8s pr\u00e9caire dans laquelle le risque et le co\u00fbt de la refonte du code monolithique ou spaghetti en unit\u00e9s ou modules sont tr\u00e8s \u00e9lev\u00e9s. Oui, le prix \u00e0 payer pour ne rien faire doit \u00eatre d\u00e9pass\u00e9 par une approche plus agile. Heureusement, les tests unitaires cr\u00e9ent le filet de s\u00e9curit\u00e9 dont vous avez besoin lorsque vous modularisez votre code existant. En g\u00e9n\u00e9rant et en relan\u00e7ant des tests unitaires sur des applications ” back-end ” au fur et \u00e0 mesure que vous les modifiez, vous vous assurez que les d\u00e9ploiements pr\u00e9c\u00e9dents fonctionnent toujours lorsqu’ils sont combin\u00e9s \u00e0 de nouvelles fonctionnalit\u00e9s.<\/p>\n
Ce type de technique de “Test Driven Maintenance” (TDM) permet d’effectuer des tests unitaires \u00e0 la demande et par lots,<\/b> comme une sorte de syst\u00e8me d’alerte pr\u00e9coce pour emp\u00eacher l’apparition de r\u00e9gressions lorsque vous “d\u00e9m\u00ealez” votre ancien code.<\/p>\n
Pour \u00eatre pleinement adopt\u00e9e par les d\u00e9veloppeurs, toute fonctionnalit\u00e9 de test unitaire sur IBM i doit \u00eatre int\u00e9gr\u00e9e dans l’environnement de d\u00e9veloppement RDi, et aussi avec des outils standards tels que Jenkins et JUnit pour encourager le partage des outils entre les \u00e9quipes multi-technologiques.<\/b> Les meilleures solutions de tests unitaires sur IBM i peuvent automatiser \u00e0 la fois la cr\u00e9ation et l’ex\u00e9cution des cas de test, en utilisant la technologie d’analyse syntaxique pour rechercher les param\u00e8tres et leurs types de donn\u00e9es et identifier rapidement toutes les entr\u00e9es et sorties du programme test\u00e9. La connaissance des r\u00e9f\u00e9rences crois\u00e9es et des d\u00e9pendances permet \u00e9galement de g\u00e9rer les cas de test et de r\u00e9utiliser les cas entre les versions.<\/p>\n<\/p>\n<\/div>\n6. L’importance de l’automatisation des tests sur IBM i<\/strong><\/h2>\nIl existe encore quelques cas extr\u00eames o\u00f9 les applications IBM i ne peuvent pas \u00eatre facilement remani\u00e9es et o\u00f9 le co\u00fbt\/temps de restructuration du code est prohibitif.<\/p>\n
Dans ce cas, l’automatisation des tests fonctionnels est la meilleure option. Les cas de test sont cr\u00e9\u00e9s automatiquement lorsque les utilisateurs ex\u00e9cutent les fonctions de l’application \u00e0 partir de l’interface utilisateur standard. Contrairement aux tests unitaires o\u00f9 l’environnement de donn\u00e9es sous-jacent est dynamique, les donn\u00e9es de test fonctionnel sont statiques et restaur\u00e9es avant chaque ex\u00e9cution de test afin de d\u00e9tecter les r\u00e9gressions par simple comparaison des donn\u00e9es, sortie spool et interface utilisateur. Il n’y a pas de notion de succ\u00e8s ou d’\u00e9chec, seulement des diff\u00e9rences<\/em>.<\/p>\n<\/p>\n
Bien s\u00fbr, une strat\u00e9gie de test optimale combine \u00e0 la fois une automatisation des tests unitaires et des tests fonctionnels pour minimiser le temps moyen de r\u00e9paration (MTTR) des d\u00e9fauts dans leur ensemble. La r\u00e9utilisation et le partage des cas de test \u00e9vitent une perte de temps co\u00fbteuse pour le d\u00e9veloppeur et font des tests une activit\u00e9 continue, partie int\u00e9grante du cycle global CI\/CD.<\/p>\n<\/p>\n
<\/div>\n7. Garantir l’adoption des tests unitaires par les d\u00e9veloppeurs<\/strong><\/h2>\nEn conclusion, nous avons vu que les tests unitaires facilitent un style de test \u00ab bottom-up \u00bb, en validant les parties individuelles d’un programme avant de tester la “somme de ses parties” <\/b>– une approche qui anticipe les d\u00e9fauts restants et r\u00e9duit l’effort des tests d’int\u00e9gration ult\u00e9rieurs.<\/p>\n
Les tests unitaires agissent comme une sorte de “documentation vivante” du syst\u00e8me, permettant une compr\u00e9hension rapide de l’interface d’une unit\u00e9. Dans le cas d’un \u00ab Test Driven Development \u00bb, ils peuvent m\u00eame remplacer une sp\u00e9cification d\u00e9taill\u00e9e.<\/p>\n
Cependant, les tests unitaires doivent \u00eatre effectu\u00e9s en parall\u00e8le avec d’autres formes de tests, car ils ne permettent pas de d\u00e9tecter les erreurs au niveau du syst\u00e8me ou les erreurs fonctionnelles, ni les aspects non fonctionnels tels que les performances.<\/p>\n
Le principal d\u00e9fi des tests unitaires est la cr\u00e9ation de tests r\u00e9alistes et utiles<\/b>, afin d’\u00e9tablir les conditions initiales pertinentes qui refl\u00e8tent l’ex\u00e9cution normale d’une application. Plus important encore, les tests unitaires doivent \u00eatre maintenus en parall\u00e8le avec le processus de changement d’application lui-m\u00eame, afin de garantir que les tests impact\u00e9s soient maintenus \u00e0 jour et ex\u00e9cut\u00e9s pour chaque changement de code d\u00e9pendant. Pour faciliter la maintenance des tests unitaires, il doit \u00eatre facile de r\u00e9-identifier les nouveaux champs d’entr\u00e9e et de sortie \u00e0 mesure que l’application \u00e9volue.<\/b> Sinon, les tests unitaires peuvent devenir aussi bogu\u00e9s que le code qu’ils sont cens\u00e9s tester !<\/p>\n
Pour surmonter ces difficult\u00e9s, les tests unitaires doivent \u00eatre hautement automatis\u00e9s et faire partie int\u00e9grante du cycle de livraison continu :<\/b><\/p>\n\n- D\u00e9tection automatique des entr\u00e9es et des sorties pour automatiser la cr\u00e9ation de tests r\u00e9alistes\/utiles<\/li>\n
- Int\u00e9gration des tests unitaires dans le processus de contr\u00f4le de version<\/li>\n
- Auto-ex\u00e9cutions des tests en tant que partie continue du flux CI\/CD<\/li>\n
- R\u00e9utilisation des actifs des tests unitaires pour chaque changement de programme<\/li>\n
- Maintenance\/mise \u00e0 jour des tests unitaires en fonction des d\u00e9pendances<\/li>\n<\/ul>\n
En r\u00e9sum\u00e9, les essais unitaires sont tr\u00e8s b\u00e9n\u00e9fiques mais imposent une certaine rigueur, n\u00e9cessitant une automatisation maximale pour une adoption \u00e0 long terme !<\/p>\n
8. La diff\u00e9rence avec Arcad i unit<\/strong><\/h2>\nARCAD iUnit<\/a> a \u00e9t\u00e9 con\u00e7u pour maximiser l’automatisation tout au long du processus de test unitaire sur IBM i. En tant que tel, il peut m\u00eame \u00eatre utilis\u00e9 par des d\u00e9veloppeurs qui ont peu ou pas de connaissances de l’application \u00e0 tester.<\/p>\nTout ce dont ARCAD iUnit a besoin pour commencer \u00e0 travailler est un nom de biblioth\u00e8que. Il en d\u00e9coule un r\u00e9f\u00e9rentiel de connaissances sur les objets contenus dans la biblioth\u00e8que, utilis\u00e9 pour aider le d\u00e9veloppeur \u00e0 chaque \u00e9tape du processus.<\/p>\n
Une fois qu’ARCAD iUnit a analys\u00e9 le contenu de la biblioth\u00e8que, l’outil guide le d\u00e9veloppeur dans la cr\u00e9ation et l’ex\u00e9cution des tests \u00e0 partir d’une interface graphique facile \u00e0 utiliser. Toutes les t\u00e2ches les plus fastidieuses sont enti\u00e8rement automatis\u00e9es, telles que :<\/b><\/p>\n\n- l’identification de toutes les proc\u00e9dures d’un programme et de leurs param\u00e8tres d’entr\u00e9e\/sortie<\/li>\n
- la d\u00e9finition des r\u00e9sultats attendus<\/li>\n
- obtention\/r\u00e9glage de valeurs<\/li>\n
- marquage\/suivi des variables<\/li>\n
- ex\u00e9cution des tests – individuellement ou en tant que suite<\/li>\n
- exportation de tests vers JUnit<\/li>\n
- ‘mocking’ de base de donn\u00e9es, pour injecter des donn\u00e9es dans une table avant l’ex\u00e9cution du test<\/li>\n
- ‘mocking’ d’un programme, pour changer le comportement par d\u00e9faut du programme<\/li>\n
- ex\u00e9cution de projet “libre”, pour g\u00e9rer les programmes manquants<\/li>\n
- int\u00e9gration avec plusieurs outils d’automatisation : Jenkins, Azure Pipelines, CloudBees, GitLab CI…<\/li>\n<\/ul>\n
L’introduction de ce niveau d’automatisation fait avancer le d\u00e9veloppement d’applications IBM i dans le monde DevOps “continu” qui est caract\u00e9ristique sur les syst\u00e8mes distribu\u00e9s – avec tous les avantages que cela apporte en termes de fiabilit\u00e9 de l’application, de retour sur investissement, d’\u00e9limination de la dette technique ou encore de continuit\u00e9 de l’activit\u00e9 pour en nommer quelques-uns.<\/p>\n
9. Conclusion<\/strong><\/h2>\nEn bref, les tests unitaires sont un maillon indispensable et souvent manquant du d\u00e9veloppement logiciel sur IBM i.<\/p>\n
Les tests unitaires automatis\u00e9s peuvent rendre un pipeline DevSecOps sur IBM i v\u00e9ritablement continu<\/b> – avec des avantages mesurables en termes de qualit\u00e9, de vitesse et de co\u00fbt.<\/p>\n
Pourtant, l’adoption des tests unitaires et le taux de retour d\u00e9pendent du degr\u00e9 d’automatisation offert par l’outil de test unitaire. Pour obtenir un portail de qualit\u00e9 s\u00e9curis\u00e9, seuls les outils capables de d\u00e9charger TOUTES les t\u00e2ches de cr\u00e9ation de tests de routine du d\u00e9veloppeur avec suffisamment de flexibilit\u00e9 pour s’adapter \u00e0 un environnement changeant, seront adopt\u00e9s \u00e0 long terme. En ce qui concerne l’IBM i, ARCAD iUnit<\/a> apporte un niveau d’automatisation sans pr\u00e9c\u00e9dent et un ROI prouv\u00e9, quelle que soit la variante de langage utilis\u00e9e.<\/p>\n<\/div><\/div><\/div>
1. La qualit\u00e9 \u00e0 partir de la quantit\u00e9<\/strong><\/h2>\n<\/p>\n
Les tests unitaires sont souvent n\u00e9glig\u00e9s au profit de techniques plus orient\u00e9es “business” comme les tests fonctionnels ou de bout en bout. Les tests unitaires prennent un temps pr\u00e9cieux aux d\u00e9veloppeurs<\/b>, surtout sur une base de code ancien comme IBM i qui n’est pas particuli\u00e8rement structur\u00e9 en “unit\u00e9s”. Alors comment un test unitaire par “bo\u00eete blanche”, sans connaissance des fonctionnalit\u00e9s r\u00e9elles de l’application, peut-il sauvegarder la qualit\u00e9 et la pr\u00e9cision de votre syst\u00e8me, sans parler de la r\u00e9duction de vos co\u00fbts de d\u00e9veloppement ?<\/p>\n
La solution r\u00e9side dans la quantit\u00e9 et la couverture des tests.<\/b><\/p>\n
Les tests unitaires impliquent la cr\u00e9ation d’une multitude de petits cas de tests tr\u00e8s simples. <\/b> Chaque test isole une section particuli\u00e8re du code (comme une proc\u00e9dure, un sous-programme, un bloc conditionnel), d\u00e9finissant le succ\u00e8s ou l’\u00e9chec en termes de valeurs attendues des param\u00e8tres de sortie pour une entr\u00e9e donn\u00e9e. L’ex\u00e9cution du test est ensuite stock\u00e9e comme “ligne de base”, et les tests ult\u00e9rieurs sont \u00e9valu\u00e9s par rapport \u00e0 ce r\u00e9sultat. Cela rend les tests unitaires tr\u00e8s efficaces pour d\u00e9tecter les r\u00e9gressions dans le syst\u00e8me. Ils peuvent \u00eatre r\u00e9utilis\u00e9s, regroup\u00e9s et ex\u00e9cut\u00e9s dans le cadre d’une suite \u00e0 tout moment, par exemple apr\u00e8s chaque build du syst\u00e8me, apr\u00e8s un changement d’environnement, ou avant qu’un composant particulier ne soit transf\u00e9r\u00e9 aux testeurs QA. Les tests unitaires cr\u00e9\u00e9s au d\u00e9but de la phase de d\u00e9veloppement peuvent \u00eatre utilis\u00e9s plus tard comme “smoke test” d’une application, afin de d\u00e9tecter les erreurs basiques et \u00e9viter de perdre du temps avec des tests plus sophistiqu\u00e9s.<\/p>\n<\/p>\n<\/div>\n2. Classification des d\u00e9fauts<\/strong><\/h2>\nEn effet, les classifications de d\u00e9fauts typiques r\u00e9v\u00e8lent que les d\u00e9fauts des logiciels peuvent \u00eatre attribu\u00e9s \u00e0 une grande vari\u00e9t\u00e9 de causes, notamment<\/b> :<\/p>\n\n- Erreurs dans la sp\u00e9cification, la conception et la mise en \u0153uvre du logiciel et du syst\u00e8me<\/li>\n
- Erreurs dans l’utilisation du syst\u00e8me<\/li>\n
- \nAnomalies dans l’environnement<\/div>\n<\/li>\n
- Dommages intentionnels<\/li>\n
- Cons\u00e9quences potentielles des erreurs ant\u00e9rieures<\/li>\n<\/ul>\n
Des enqu\u00eates r\u00e9centes ont montr\u00e9 que jusqu\u2019\u00e0 55 % des d\u00e9fauts sont dus \u00e0 des erreurs pr\u00e9sentes dans le cahier des charges.<\/b><\/p>\n
Il a \u00e9galement \u00e9t\u00e9 observ\u00e9 qu’environ 40 % du temps d’un testeur est consacr\u00e9 aux anomalies d’environnement<\/b>, ce qui a un impact important sur la qualit\u00e9 et la productivit\u00e9.<\/p>\n
Les nombreuses causes “p\u00e9riph\u00e9riques” des d\u00e9fauts signifient que les co\u00fbts globaux des tests peuvent \u00eatre consid\u00e9rablement r\u00e9duits en r\u00e9utilisant les cas de tests unitaires dans les “smoke tests”, avant d’entreprendre des tests de syst\u00e8mes co\u00fbteux \u00e0 grande \u00e9chelle.<\/p>\n
<\/p>\n<\/div><\/div><\/div>
D\u00e9couvrez comment ARCAD for DevOps permet de contr\u00f4ler les co\u00fbts et d\u2019acc\u00e9l\u00e9rer les d\u00e9ploiements d\u2019applications dans des environnements technologiques h\u00e9t\u00e9rog\u00e8nes.<\/strong><\/p>\n<\/div>T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. “Shift Left” – d\u00e9tecter les erreurs le plus t\u00f4t possible<\/strong><\/h2>\nLes tests unitaires ne sont qu’une des nombreuses techniques des d\u00e9veloppeurs qui permettent de d\u00e9tecter les d\u00e9fauts le plus t\u00f4t possible dans le cycle de d\u00e9veloppement. Outre l’analyse statique du code, l’examen du code par les pairs, l’analyse de la couverture du code et d’autres pratiques, les tests unitaires permettent de d\u00e9tecter les erreurs le plus t\u00f4t possible,<\/b> au moment o\u00f9 elles sont le moins co\u00fbteuses.<\/p>\n
L’investissement en temps du d\u00e9veloppeur pour cr\u00e9er le test dans un premier temps peut \u00eatre compens\u00e9 par l’automatisation du processus de cr\u00e9ation. L’essentiel est de se concentrer sur des cas d’utilisation typiques qui affectent le comportement du syst\u00e8me. La combinaison de “happy path” et de “edge cases” rend les tests unitaires encore plus efficaces.<\/p>\n
Utilis\u00e9s en continu dans un cycle CI\/CD, les tests unitaires permettent de d\u00e9terminer pr\u00e9cis\u00e9ment dans quelles lignes de code se trouve le d\u00e9faut<\/b>. Les bugs sont corrig\u00e9s avant m\u00eame qu’ils ne quittent les mains du d\u00e9veloppeur !<\/p>\n<\/p>\n<\/div>\n4. Un code \u2018atomique\u2019 propre<\/strong><\/h2>\nPlus de 90 % des co\u00fbts de d\u00e9veloppement de logiciels sont consacr\u00e9s \u00e0 la maintenance des syst\u00e8mes existants<\/b>. La cr\u00e9ation de tests unitaires au fur et \u00e0 mesure que vous d\u00e9veloppez du code am\u00e9liore la conception du code et le rend plus facile \u00e0 comprendre par les \u00e9quipes de d\u00e9veloppement futures. En plus d’\u00eatre plus fiable, le code test\u00e9 \u00e0 l’unit\u00e9 est plus simple, plus modulaire et donc plus facilement r\u00e9utilisable. Cela permet de r\u00e9duire la dette technique et de diminuer les co\u00fbts de d\u00e9veloppement \u00e0 long terme.<\/p>\n
Dans sa forme extr\u00eame, le “Test Driven Development” apporte une clart\u00e9 suppl\u00e9mentaire m\u00eame lors de la d\u00e9finition des pr\u00e9requis en cr\u00e9ant des tests avant le code lui-m\u00eame.<\/p>\n<\/p>\n
<\/div>\n5. Qu’en est-il de l’IBM i ?<\/strong><\/h2>\nLes applications IBM i modernes con\u00e7ues avec une architecture ILE s\u00e9parent d\u00e9j\u00e0 les r\u00e8gles de gestion, la persistance des donn\u00e9es et l’interface utilisateur en modules ou fonctions distincts, ce qui facilite grandement l’automatisation des tests unitaires. Les points d’entr\u00e9e et de sortie d’un module sont clairs, de sorte qu’il est relativement facile de d\u00e9finir un \u00e9tat “r\u00e9ussite\/\u00e9chec”.<\/p>\n
Cependant, de nombreuses applications sur IBM i contiennent encore des sections de code source qui ont \u00e9t\u00e9 d\u00e9velopp\u00e9es il y a 40 ans et qui sont “trop importantes pour \u00eatre touch\u00e9es”. Cela cr\u00e9e une situation tr\u00e8s pr\u00e9caire dans laquelle le risque et le co\u00fbt de la refonte du code monolithique ou spaghetti en unit\u00e9s ou modules sont tr\u00e8s \u00e9lev\u00e9s. Oui, le prix \u00e0 payer pour ne rien faire doit \u00eatre d\u00e9pass\u00e9 par une approche plus agile. Heureusement, les tests unitaires cr\u00e9ent le filet de s\u00e9curit\u00e9 dont vous avez besoin lorsque vous modularisez votre code existant. En g\u00e9n\u00e9rant et en relan\u00e7ant des tests unitaires sur des applications ” back-end ” au fur et \u00e0 mesure que vous les modifiez, vous vous assurez que les d\u00e9ploiements pr\u00e9c\u00e9dents fonctionnent toujours lorsqu’ils sont combin\u00e9s \u00e0 de nouvelles fonctionnalit\u00e9s.<\/p>\n
Ce type de technique de “Test Driven Maintenance” (TDM) permet d’effectuer des tests unitaires \u00e0 la demande et par lots,<\/b> comme une sorte de syst\u00e8me d’alerte pr\u00e9coce pour emp\u00eacher l’apparition de r\u00e9gressions lorsque vous “d\u00e9m\u00ealez” votre ancien code.<\/p>\n
Pour \u00eatre pleinement adopt\u00e9e par les d\u00e9veloppeurs, toute fonctionnalit\u00e9 de test unitaire sur IBM i doit \u00eatre int\u00e9gr\u00e9e dans l’environnement de d\u00e9veloppement RDi, et aussi avec des outils standards tels que Jenkins et JUnit pour encourager le partage des outils entre les \u00e9quipes multi-technologiques.<\/b> Les meilleures solutions de tests unitaires sur IBM i peuvent automatiser \u00e0 la fois la cr\u00e9ation et l’ex\u00e9cution des cas de test, en utilisant la technologie d’analyse syntaxique pour rechercher les param\u00e8tres et leurs types de donn\u00e9es et identifier rapidement toutes les entr\u00e9es et sorties du programme test\u00e9. La connaissance des r\u00e9f\u00e9rences crois\u00e9es et des d\u00e9pendances permet \u00e9galement de g\u00e9rer les cas de test et de r\u00e9utiliser les cas entre les versions.<\/p>\n<\/p>\n<\/div>\n6. L’importance de l’automatisation des tests sur IBM i<\/strong><\/h2>\nIl existe encore quelques cas extr\u00eames o\u00f9 les applications IBM i ne peuvent pas \u00eatre facilement remani\u00e9es et o\u00f9 le co\u00fbt\/temps de restructuration du code est prohibitif.<\/p>\n
Dans ce cas, l’automatisation des tests fonctionnels est la meilleure option. Les cas de test sont cr\u00e9\u00e9s automatiquement lorsque les utilisateurs ex\u00e9cutent les fonctions de l’application \u00e0 partir de l’interface utilisateur standard. Contrairement aux tests unitaires o\u00f9 l’environnement de donn\u00e9es sous-jacent est dynamique, les donn\u00e9es de test fonctionnel sont statiques et restaur\u00e9es avant chaque ex\u00e9cution de test afin de d\u00e9tecter les r\u00e9gressions par simple comparaison des donn\u00e9es, sortie spool et interface utilisateur. Il n’y a pas de notion de succ\u00e8s ou d’\u00e9chec, seulement des diff\u00e9rences<\/em>.<\/p>\n<\/p>\n
Bien s\u00fbr, une strat\u00e9gie de test optimale combine \u00e0 la fois une automatisation des tests unitaires et des tests fonctionnels pour minimiser le temps moyen de r\u00e9paration (MTTR) des d\u00e9fauts dans leur ensemble. La r\u00e9utilisation et le partage des cas de test \u00e9vitent une perte de temps co\u00fbteuse pour le d\u00e9veloppeur et font des tests une activit\u00e9 continue, partie int\u00e9grante du cycle global CI\/CD.<\/p>\n<\/p>\n
<\/div>\n7. Garantir l’adoption des tests unitaires par les d\u00e9veloppeurs<\/strong><\/h2>\nEn conclusion, nous avons vu que les tests unitaires facilitent un style de test \u00ab bottom-up \u00bb, en validant les parties individuelles d’un programme avant de tester la “somme de ses parties” <\/b>– une approche qui anticipe les d\u00e9fauts restants et r\u00e9duit l’effort des tests d’int\u00e9gration ult\u00e9rieurs.<\/p>\n
Les tests unitaires agissent comme une sorte de “documentation vivante” du syst\u00e8me, permettant une compr\u00e9hension rapide de l’interface d’une unit\u00e9. Dans le cas d’un \u00ab Test Driven Development \u00bb, ils peuvent m\u00eame remplacer une sp\u00e9cification d\u00e9taill\u00e9e.<\/p>\n
Cependant, les tests unitaires doivent \u00eatre effectu\u00e9s en parall\u00e8le avec d’autres formes de tests, car ils ne permettent pas de d\u00e9tecter les erreurs au niveau du syst\u00e8me ou les erreurs fonctionnelles, ni les aspects non fonctionnels tels que les performances.<\/p>\n
Le principal d\u00e9fi des tests unitaires est la cr\u00e9ation de tests r\u00e9alistes et utiles<\/b>, afin d’\u00e9tablir les conditions initiales pertinentes qui refl\u00e8tent l’ex\u00e9cution normale d’une application. Plus important encore, les tests unitaires doivent \u00eatre maintenus en parall\u00e8le avec le processus de changement d’application lui-m\u00eame, afin de garantir que les tests impact\u00e9s soient maintenus \u00e0 jour et ex\u00e9cut\u00e9s pour chaque changement de code d\u00e9pendant. Pour faciliter la maintenance des tests unitaires, il doit \u00eatre facile de r\u00e9-identifier les nouveaux champs d’entr\u00e9e et de sortie \u00e0 mesure que l’application \u00e9volue.<\/b> Sinon, les tests unitaires peuvent devenir aussi bogu\u00e9s que le code qu’ils sont cens\u00e9s tester !<\/p>\n
Pour surmonter ces difficult\u00e9s, les tests unitaires doivent \u00eatre hautement automatis\u00e9s et faire partie int\u00e9grante du cycle de livraison continu :<\/b><\/p>\n\n- D\u00e9tection automatique des entr\u00e9es et des sorties pour automatiser la cr\u00e9ation de tests r\u00e9alistes\/utiles<\/li>\n
- Int\u00e9gration des tests unitaires dans le processus de contr\u00f4le de version<\/li>\n
- Auto-ex\u00e9cutions des tests en tant que partie continue du flux CI\/CD<\/li>\n
- R\u00e9utilisation des actifs des tests unitaires pour chaque changement de programme<\/li>\n
- Maintenance\/mise \u00e0 jour des tests unitaires en fonction des d\u00e9pendances<\/li>\n<\/ul>\n
En r\u00e9sum\u00e9, les essais unitaires sont tr\u00e8s b\u00e9n\u00e9fiques mais imposent une certaine rigueur, n\u00e9cessitant une automatisation maximale pour une adoption \u00e0 long terme !<\/p>\n
8. La diff\u00e9rence avec Arcad i unit<\/strong><\/h2>\nARCAD iUnit<\/a> a \u00e9t\u00e9 con\u00e7u pour maximiser l’automatisation tout au long du processus de test unitaire sur IBM i. En tant que tel, il peut m\u00eame \u00eatre utilis\u00e9 par des d\u00e9veloppeurs qui ont peu ou pas de connaissances de l’application \u00e0 tester.<\/p>\nTout ce dont ARCAD iUnit a besoin pour commencer \u00e0 travailler est un nom de biblioth\u00e8que. Il en d\u00e9coule un r\u00e9f\u00e9rentiel de connaissances sur les objets contenus dans la biblioth\u00e8que, utilis\u00e9 pour aider le d\u00e9veloppeur \u00e0 chaque \u00e9tape du processus.<\/p>\n
Une fois qu’ARCAD iUnit a analys\u00e9 le contenu de la biblioth\u00e8que, l’outil guide le d\u00e9veloppeur dans la cr\u00e9ation et l’ex\u00e9cution des tests \u00e0 partir d’une interface graphique facile \u00e0 utiliser. Toutes les t\u00e2ches les plus fastidieuses sont enti\u00e8rement automatis\u00e9es, telles que :<\/b><\/p>\n\n- l’identification de toutes les proc\u00e9dures d’un programme et de leurs param\u00e8tres d’entr\u00e9e\/sortie<\/li>\n
- la d\u00e9finition des r\u00e9sultats attendus<\/li>\n
- obtention\/r\u00e9glage de valeurs<\/li>\n
- marquage\/suivi des variables<\/li>\n
- ex\u00e9cution des tests – individuellement ou en tant que suite<\/li>\n
- exportation de tests vers JUnit<\/li>\n
- ‘mocking’ de base de donn\u00e9es, pour injecter des donn\u00e9es dans une table avant l’ex\u00e9cution du test<\/li>\n
- ‘mocking’ d’un programme, pour changer le comportement par d\u00e9faut du programme<\/li>\n
- ex\u00e9cution de projet “libre”, pour g\u00e9rer les programmes manquants<\/li>\n
- int\u00e9gration avec plusieurs outils d’automatisation : Jenkins, Azure Pipelines, CloudBees, GitLab CI…<\/li>\n<\/ul>\n
L’introduction de ce niveau d’automatisation fait avancer le d\u00e9veloppement d’applications IBM i dans le monde DevOps “continu” qui est caract\u00e9ristique sur les syst\u00e8mes distribu\u00e9s – avec tous les avantages que cela apporte en termes de fiabilit\u00e9 de l’application, de retour sur investissement, d’\u00e9limination de la dette technique ou encore de continuit\u00e9 de l’activit\u00e9 pour en nommer quelques-uns.<\/p>\n
9. Conclusion<\/strong><\/h2>\nEn bref, les tests unitaires sont un maillon indispensable et souvent manquant du d\u00e9veloppement logiciel sur IBM i.<\/p>\n
Les tests unitaires automatis\u00e9s peuvent rendre un pipeline DevSecOps sur IBM i v\u00e9ritablement continu<\/b> – avec des avantages mesurables en termes de qualit\u00e9, de vitesse et de co\u00fbt.<\/p>\n
Pourtant, l’adoption des tests unitaires et le taux de retour d\u00e9pendent du degr\u00e9 d’automatisation offert par l’outil de test unitaire. Pour obtenir un portail de qualit\u00e9 s\u00e9curis\u00e9, seuls les outils capables de d\u00e9charger TOUTES les t\u00e2ches de cr\u00e9ation de tests de routine du d\u00e9veloppeur avec suffisamment de flexibilit\u00e9 pour s’adapter \u00e0 un environnement changeant, seront adopt\u00e9s \u00e0 long terme. En ce qui concerne l’IBM i, ARCAD iUnit<\/a> apporte un niveau d’automatisation sans pr\u00e9c\u00e9dent et un ROI prouv\u00e9, quelle que soit la variante de langage utilis\u00e9e.<\/p>\n<\/div><\/div><\/div>
<\/p>\n2. Classification des d\u00e9fauts<\/strong><\/h2>\nEn effet, les classifications de d\u00e9fauts typiques r\u00e9v\u00e8lent que les d\u00e9fauts des logiciels peuvent \u00eatre attribu\u00e9s \u00e0 une grande vari\u00e9t\u00e9 de causes, notamment<\/b> :<\/p>\n\n- Erreurs dans la sp\u00e9cification, la conception et la mise en \u0153uvre du logiciel et du syst\u00e8me<\/li>\n
- Erreurs dans l’utilisation du syst\u00e8me<\/li>\n
- \nAnomalies dans l’environnement<\/div>\n<\/li>\n
- Dommages intentionnels<\/li>\n
- Cons\u00e9quences potentielles des erreurs ant\u00e9rieures<\/li>\n<\/ul>\n
Des enqu\u00eates r\u00e9centes ont montr\u00e9 que jusqu\u2019\u00e0 55 % des d\u00e9fauts sont dus \u00e0 des erreurs pr\u00e9sentes dans le cahier des charges.<\/b><\/p>\n
Il a \u00e9galement \u00e9t\u00e9 observ\u00e9 qu’environ 40 % du temps d’un testeur est consacr\u00e9 aux anomalies d’environnement<\/b>, ce qui a un impact important sur la qualit\u00e9 et la productivit\u00e9.<\/p>\n
Les nombreuses causes “p\u00e9riph\u00e9riques” des d\u00e9fauts signifient que les co\u00fbts globaux des tests peuvent \u00eatre consid\u00e9rablement r\u00e9duits en r\u00e9utilisant les cas de tests unitaires dans les “smoke tests”, avant d’entreprendre des tests de syst\u00e8mes co\u00fbteux \u00e0 grande \u00e9chelle.<\/p>\n
<\/p>\n<\/div><\/div><\/div>
D\u00e9couvrez comment ARCAD for DevOps permet de contr\u00f4ler les co\u00fbts et d\u2019acc\u00e9l\u00e9rer les d\u00e9ploiements d\u2019applications dans des environnements technologiques h\u00e9t\u00e9rog\u00e8nes.<\/strong><\/p>\n<\/div>T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. “Shift Left” – d\u00e9tecter les erreurs le plus t\u00f4t possible<\/strong><\/h2>\nLes tests unitaires ne sont qu’une des nombreuses techniques des d\u00e9veloppeurs qui permettent de d\u00e9tecter les d\u00e9fauts le plus t\u00f4t possible dans le cycle de d\u00e9veloppement. Outre l’analyse statique du code, l’examen du code par les pairs, l’analyse de la couverture du code et d’autres pratiques, les tests unitaires permettent de d\u00e9tecter les erreurs le plus t\u00f4t possible,<\/b> au moment o\u00f9 elles sont le moins co\u00fbteuses.<\/p>\n
L’investissement en temps du d\u00e9veloppeur pour cr\u00e9er le test dans un premier temps peut \u00eatre compens\u00e9 par l’automatisation du processus de cr\u00e9ation. L’essentiel est de se concentrer sur des cas d’utilisation typiques qui affectent le comportement du syst\u00e8me. La combinaison de “happy path” et de “edge cases” rend les tests unitaires encore plus efficaces.<\/p>\n
Utilis\u00e9s en continu dans un cycle CI\/CD, les tests unitaires permettent de d\u00e9terminer pr\u00e9cis\u00e9ment dans quelles lignes de code se trouve le d\u00e9faut<\/b>. Les bugs sont corrig\u00e9s avant m\u00eame qu’ils ne quittent les mains du d\u00e9veloppeur !<\/p>\n<\/p>\n<\/div>\n4. Un code \u2018atomique\u2019 propre<\/strong><\/h2>\nPlus de 90 % des co\u00fbts de d\u00e9veloppement de logiciels sont consacr\u00e9s \u00e0 la maintenance des syst\u00e8mes existants<\/b>. La cr\u00e9ation de tests unitaires au fur et \u00e0 mesure que vous d\u00e9veloppez du code am\u00e9liore la conception du code et le rend plus facile \u00e0 comprendre par les \u00e9quipes de d\u00e9veloppement futures. En plus d’\u00eatre plus fiable, le code test\u00e9 \u00e0 l’unit\u00e9 est plus simple, plus modulaire et donc plus facilement r\u00e9utilisable. Cela permet de r\u00e9duire la dette technique et de diminuer les co\u00fbts de d\u00e9veloppement \u00e0 long terme.<\/p>\n
Dans sa forme extr\u00eame, le “Test Driven Development” apporte une clart\u00e9 suppl\u00e9mentaire m\u00eame lors de la d\u00e9finition des pr\u00e9requis en cr\u00e9ant des tests avant le code lui-m\u00eame.<\/p>\n<\/p>\n
<\/div>\n5. Qu’en est-il de l’IBM i ?<\/strong><\/h2>\nLes applications IBM i modernes con\u00e7ues avec une architecture ILE s\u00e9parent d\u00e9j\u00e0 les r\u00e8gles de gestion, la persistance des donn\u00e9es et l’interface utilisateur en modules ou fonctions distincts, ce qui facilite grandement l’automatisation des tests unitaires. Les points d’entr\u00e9e et de sortie d’un module sont clairs, de sorte qu’il est relativement facile de d\u00e9finir un \u00e9tat “r\u00e9ussite\/\u00e9chec”.<\/p>\n
Cependant, de nombreuses applications sur IBM i contiennent encore des sections de code source qui ont \u00e9t\u00e9 d\u00e9velopp\u00e9es il y a 40 ans et qui sont “trop importantes pour \u00eatre touch\u00e9es”. Cela cr\u00e9e une situation tr\u00e8s pr\u00e9caire dans laquelle le risque et le co\u00fbt de la refonte du code monolithique ou spaghetti en unit\u00e9s ou modules sont tr\u00e8s \u00e9lev\u00e9s. Oui, le prix \u00e0 payer pour ne rien faire doit \u00eatre d\u00e9pass\u00e9 par une approche plus agile. Heureusement, les tests unitaires cr\u00e9ent le filet de s\u00e9curit\u00e9 dont vous avez besoin lorsque vous modularisez votre code existant. En g\u00e9n\u00e9rant et en relan\u00e7ant des tests unitaires sur des applications ” back-end ” au fur et \u00e0 mesure que vous les modifiez, vous vous assurez que les d\u00e9ploiements pr\u00e9c\u00e9dents fonctionnent toujours lorsqu’ils sont combin\u00e9s \u00e0 de nouvelles fonctionnalit\u00e9s.<\/p>\n
Ce type de technique de “Test Driven Maintenance” (TDM) permet d’effectuer des tests unitaires \u00e0 la demande et par lots,<\/b> comme une sorte de syst\u00e8me d’alerte pr\u00e9coce pour emp\u00eacher l’apparition de r\u00e9gressions lorsque vous “d\u00e9m\u00ealez” votre ancien code.<\/p>\n
Pour \u00eatre pleinement adopt\u00e9e par les d\u00e9veloppeurs, toute fonctionnalit\u00e9 de test unitaire sur IBM i doit \u00eatre int\u00e9gr\u00e9e dans l’environnement de d\u00e9veloppement RDi, et aussi avec des outils standards tels que Jenkins et JUnit pour encourager le partage des outils entre les \u00e9quipes multi-technologiques.<\/b> Les meilleures solutions de tests unitaires sur IBM i peuvent automatiser \u00e0 la fois la cr\u00e9ation et l’ex\u00e9cution des cas de test, en utilisant la technologie d’analyse syntaxique pour rechercher les param\u00e8tres et leurs types de donn\u00e9es et identifier rapidement toutes les entr\u00e9es et sorties du programme test\u00e9. La connaissance des r\u00e9f\u00e9rences crois\u00e9es et des d\u00e9pendances permet \u00e9galement de g\u00e9rer les cas de test et de r\u00e9utiliser les cas entre les versions.<\/p>\n<\/p>\n<\/div>\n6. L’importance de l’automatisation des tests sur IBM i<\/strong><\/h2>\nIl existe encore quelques cas extr\u00eames o\u00f9 les applications IBM i ne peuvent pas \u00eatre facilement remani\u00e9es et o\u00f9 le co\u00fbt\/temps de restructuration du code est prohibitif.<\/p>\n
Dans ce cas, l’automatisation des tests fonctionnels est la meilleure option. Les cas de test sont cr\u00e9\u00e9s automatiquement lorsque les utilisateurs ex\u00e9cutent les fonctions de l’application \u00e0 partir de l’interface utilisateur standard. Contrairement aux tests unitaires o\u00f9 l’environnement de donn\u00e9es sous-jacent est dynamique, les donn\u00e9es de test fonctionnel sont statiques et restaur\u00e9es avant chaque ex\u00e9cution de test afin de d\u00e9tecter les r\u00e9gressions par simple comparaison des donn\u00e9es, sortie spool et interface utilisateur. Il n’y a pas de notion de succ\u00e8s ou d’\u00e9chec, seulement des diff\u00e9rences<\/em>.<\/p>\n<\/p>\n
Bien s\u00fbr, une strat\u00e9gie de test optimale combine \u00e0 la fois une automatisation des tests unitaires et des tests fonctionnels pour minimiser le temps moyen de r\u00e9paration (MTTR) des d\u00e9fauts dans leur ensemble. La r\u00e9utilisation et le partage des cas de test \u00e9vitent une perte de temps co\u00fbteuse pour le d\u00e9veloppeur et font des tests une activit\u00e9 continue, partie int\u00e9grante du cycle global CI\/CD.<\/p>\n<\/p>\n
<\/div>\n7. Garantir l’adoption des tests unitaires par les d\u00e9veloppeurs<\/strong><\/h2>\nEn conclusion, nous avons vu que les tests unitaires facilitent un style de test \u00ab bottom-up \u00bb, en validant les parties individuelles d’un programme avant de tester la “somme de ses parties” <\/b>– une approche qui anticipe les d\u00e9fauts restants et r\u00e9duit l’effort des tests d’int\u00e9gration ult\u00e9rieurs.<\/p>\n
Les tests unitaires agissent comme une sorte de “documentation vivante” du syst\u00e8me, permettant une compr\u00e9hension rapide de l’interface d’une unit\u00e9. Dans le cas d’un \u00ab Test Driven Development \u00bb, ils peuvent m\u00eame remplacer une sp\u00e9cification d\u00e9taill\u00e9e.<\/p>\n
Cependant, les tests unitaires doivent \u00eatre effectu\u00e9s en parall\u00e8le avec d’autres formes de tests, car ils ne permettent pas de d\u00e9tecter les erreurs au niveau du syst\u00e8me ou les erreurs fonctionnelles, ni les aspects non fonctionnels tels que les performances.<\/p>\n
Le principal d\u00e9fi des tests unitaires est la cr\u00e9ation de tests r\u00e9alistes et utiles<\/b>, afin d’\u00e9tablir les conditions initiales pertinentes qui refl\u00e8tent l’ex\u00e9cution normale d’une application. Plus important encore, les tests unitaires doivent \u00eatre maintenus en parall\u00e8le avec le processus de changement d’application lui-m\u00eame, afin de garantir que les tests impact\u00e9s soient maintenus \u00e0 jour et ex\u00e9cut\u00e9s pour chaque changement de code d\u00e9pendant. Pour faciliter la maintenance des tests unitaires, il doit \u00eatre facile de r\u00e9-identifier les nouveaux champs d’entr\u00e9e et de sortie \u00e0 mesure que l’application \u00e9volue.<\/b> Sinon, les tests unitaires peuvent devenir aussi bogu\u00e9s que le code qu’ils sont cens\u00e9s tester !<\/p>\n
Pour surmonter ces difficult\u00e9s, les tests unitaires doivent \u00eatre hautement automatis\u00e9s et faire partie int\u00e9grante du cycle de livraison continu :<\/b><\/p>\n\n- D\u00e9tection automatique des entr\u00e9es et des sorties pour automatiser la cr\u00e9ation de tests r\u00e9alistes\/utiles<\/li>\n
- Int\u00e9gration des tests unitaires dans le processus de contr\u00f4le de version<\/li>\n
- Auto-ex\u00e9cutions des tests en tant que partie continue du flux CI\/CD<\/li>\n
- R\u00e9utilisation des actifs des tests unitaires pour chaque changement de programme<\/li>\n
- Maintenance\/mise \u00e0 jour des tests unitaires en fonction des d\u00e9pendances<\/li>\n<\/ul>\n
En r\u00e9sum\u00e9, les essais unitaires sont tr\u00e8s b\u00e9n\u00e9fiques mais imposent une certaine rigueur, n\u00e9cessitant une automatisation maximale pour une adoption \u00e0 long terme !<\/p>\n
8. La diff\u00e9rence avec Arcad i unit<\/strong><\/h2>\nARCAD iUnit<\/a> a \u00e9t\u00e9 con\u00e7u pour maximiser l’automatisation tout au long du processus de test unitaire sur IBM i. En tant que tel, il peut m\u00eame \u00eatre utilis\u00e9 par des d\u00e9veloppeurs qui ont peu ou pas de connaissances de l’application \u00e0 tester.<\/p>\nTout ce dont ARCAD iUnit a besoin pour commencer \u00e0 travailler est un nom de biblioth\u00e8que. Il en d\u00e9coule un r\u00e9f\u00e9rentiel de connaissances sur les objets contenus dans la biblioth\u00e8que, utilis\u00e9 pour aider le d\u00e9veloppeur \u00e0 chaque \u00e9tape du processus.<\/p>\n
Une fois qu’ARCAD iUnit a analys\u00e9 le contenu de la biblioth\u00e8que, l’outil guide le d\u00e9veloppeur dans la cr\u00e9ation et l’ex\u00e9cution des tests \u00e0 partir d’une interface graphique facile \u00e0 utiliser. Toutes les t\u00e2ches les plus fastidieuses sont enti\u00e8rement automatis\u00e9es, telles que :<\/b><\/p>\n\n- l’identification de toutes les proc\u00e9dures d’un programme et de leurs param\u00e8tres d’entr\u00e9e\/sortie<\/li>\n
- la d\u00e9finition des r\u00e9sultats attendus<\/li>\n
- obtention\/r\u00e9glage de valeurs<\/li>\n
- marquage\/suivi des variables<\/li>\n
- ex\u00e9cution des tests – individuellement ou en tant que suite<\/li>\n
- exportation de tests vers JUnit<\/li>\n
- ‘mocking’ de base de donn\u00e9es, pour injecter des donn\u00e9es dans une table avant l’ex\u00e9cution du test<\/li>\n
- ‘mocking’ d’un programme, pour changer le comportement par d\u00e9faut du programme<\/li>\n
- ex\u00e9cution de projet “libre”, pour g\u00e9rer les programmes manquants<\/li>\n
- int\u00e9gration avec plusieurs outils d’automatisation : Jenkins, Azure Pipelines, CloudBees, GitLab CI…<\/li>\n<\/ul>\n
L’introduction de ce niveau d’automatisation fait avancer le d\u00e9veloppement d’applications IBM i dans le monde DevOps “continu” qui est caract\u00e9ristique sur les syst\u00e8mes distribu\u00e9s – avec tous les avantages que cela apporte en termes de fiabilit\u00e9 de l’application, de retour sur investissement, d’\u00e9limination de la dette technique ou encore de continuit\u00e9 de l’activit\u00e9 pour en nommer quelques-uns.<\/p>\n
9. Conclusion<\/strong><\/h2>\nEn bref, les tests unitaires sont un maillon indispensable et souvent manquant du d\u00e9veloppement logiciel sur IBM i.<\/p>\n
Les tests unitaires automatis\u00e9s peuvent rendre un pipeline DevSecOps sur IBM i v\u00e9ritablement continu<\/b> – avec des avantages mesurables en termes de qualit\u00e9, de vitesse et de co\u00fbt.<\/p>\n
Pourtant, l’adoption des tests unitaires et le taux de retour d\u00e9pendent du degr\u00e9 d’automatisation offert par l’outil de test unitaire. Pour obtenir un portail de qualit\u00e9 s\u00e9curis\u00e9, seuls les outils capables de d\u00e9charger TOUTES les t\u00e2ches de cr\u00e9ation de tests de routine du d\u00e9veloppeur avec suffisamment de flexibilit\u00e9 pour s’adapter \u00e0 un environnement changeant, seront adopt\u00e9s \u00e0 long terme. En ce qui concerne l’IBM i, ARCAD iUnit<\/a> apporte un niveau d’automatisation sans pr\u00e9c\u00e9dent et un ROI prouv\u00e9, quelle que soit la variante de langage utilis\u00e9e.<\/p>\n<\/div><\/div><\/div>
- \n
- Erreurs dans la sp\u00e9cification, la conception et la mise en \u0153uvre du logiciel et du syst\u00e8me<\/li>\n
- Erreurs dans l’utilisation du syst\u00e8me<\/li>\n
- \nAnomalies dans l’environnement<\/div>\n<\/li>\n
- Dommages intentionnels<\/li>\n
- Cons\u00e9quences potentielles des erreurs ant\u00e9rieures<\/li>\n<\/ul>\n
Des enqu\u00eates r\u00e9centes ont montr\u00e9 que jusqu\u2019\u00e0 55 % des d\u00e9fauts sont dus \u00e0 des erreurs pr\u00e9sentes dans le cahier des charges.<\/b><\/p>\n
Il a \u00e9galement \u00e9t\u00e9 observ\u00e9 qu’environ 40 % du temps d’un testeur est consacr\u00e9 aux anomalies d’environnement<\/b>, ce qui a un impact important sur la qualit\u00e9 et la productivit\u00e9.<\/p>\n
Les nombreuses causes “p\u00e9riph\u00e9riques” des d\u00e9fauts signifient que les co\u00fbts globaux des tests peuvent \u00eatre consid\u00e9rablement r\u00e9duits en r\u00e9utilisant les cas de tests unitaires dans les “smoke tests”, avant d’entreprendre des tests de syst\u00e8mes co\u00fbteux \u00e0 grande \u00e9chelle.<\/p>\n
<\/p>\n<\/div><\/div><\/div>D\u00e9couvrez comment ARCAD for DevOps permet de contr\u00f4ler les co\u00fbts et d\u2019acc\u00e9l\u00e9rer les d\u00e9ploiements d\u2019applications dans des environnements technologiques h\u00e9t\u00e9rog\u00e8nes.<\/strong><\/p>\n<\/div>
T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. “Shift Left” – d\u00e9tecter les erreurs le plus t\u00f4t possible<\/strong><\/h2>\n
Les tests unitaires ne sont qu’une des nombreuses techniques des d\u00e9veloppeurs qui permettent de d\u00e9tecter les d\u00e9fauts le plus t\u00f4t possible dans le cycle de d\u00e9veloppement. Outre l’analyse statique du code, l’examen du code par les pairs, l’analyse de la couverture du code et d’autres pratiques, les tests unitaires permettent de d\u00e9tecter les erreurs le plus t\u00f4t possible,<\/b> au moment o\u00f9 elles sont le moins co\u00fbteuses.<\/p>\n
L’investissement en temps du d\u00e9veloppeur pour cr\u00e9er le test dans un premier temps peut \u00eatre compens\u00e9 par l’automatisation du processus de cr\u00e9ation. L’essentiel est de se concentrer sur des cas d’utilisation typiques qui affectent le comportement du syst\u00e8me. La combinaison de “happy path” et de “edge cases” rend les tests unitaires encore plus efficaces.<\/p>\n
Utilis\u00e9s en continu dans un cycle CI\/CD, les tests unitaires permettent de d\u00e9terminer pr\u00e9cis\u00e9ment dans quelles lignes de code se trouve le d\u00e9faut<\/b>. Les bugs sont corrig\u00e9s avant m\u00eame qu’ils ne quittent les mains du d\u00e9veloppeur !<\/p>\n<\/p>\n
<\/div>\n4. Un code \u2018atomique\u2019 propre<\/strong><\/h2>\n
Plus de 90 % des co\u00fbts de d\u00e9veloppement de logiciels sont consacr\u00e9s \u00e0 la maintenance des syst\u00e8mes existants<\/b>. La cr\u00e9ation de tests unitaires au fur et \u00e0 mesure que vous d\u00e9veloppez du code am\u00e9liore la conception du code et le rend plus facile \u00e0 comprendre par les \u00e9quipes de d\u00e9veloppement futures. En plus d’\u00eatre plus fiable, le code test\u00e9 \u00e0 l’unit\u00e9 est plus simple, plus modulaire et donc plus facilement r\u00e9utilisable. Cela permet de r\u00e9duire la dette technique et de diminuer les co\u00fbts de d\u00e9veloppement \u00e0 long terme.<\/p>\n
Dans sa forme extr\u00eame, le “Test Driven Development” apporte une clart\u00e9 suppl\u00e9mentaire m\u00eame lors de la d\u00e9finition des pr\u00e9requis en cr\u00e9ant des tests avant le code lui-m\u00eame.<\/p>\n<\/p>\n
<\/div>\n5. Qu’en est-il de l’IBM i ?<\/strong><\/h2>\n
Les applications IBM i modernes con\u00e7ues avec une architecture ILE s\u00e9parent d\u00e9j\u00e0 les r\u00e8gles de gestion, la persistance des donn\u00e9es et l’interface utilisateur en modules ou fonctions distincts, ce qui facilite grandement l’automatisation des tests unitaires. Les points d’entr\u00e9e et de sortie d’un module sont clairs, de sorte qu’il est relativement facile de d\u00e9finir un \u00e9tat “r\u00e9ussite\/\u00e9chec”.<\/p>\n
Cependant, de nombreuses applications sur IBM i contiennent encore des sections de code source qui ont \u00e9t\u00e9 d\u00e9velopp\u00e9es il y a 40 ans et qui sont “trop importantes pour \u00eatre touch\u00e9es”. Cela cr\u00e9e une situation tr\u00e8s pr\u00e9caire dans laquelle le risque et le co\u00fbt de la refonte du code monolithique ou spaghetti en unit\u00e9s ou modules sont tr\u00e8s \u00e9lev\u00e9s. Oui, le prix \u00e0 payer pour ne rien faire doit \u00eatre d\u00e9pass\u00e9 par une approche plus agile. Heureusement, les tests unitaires cr\u00e9ent le filet de s\u00e9curit\u00e9 dont vous avez besoin lorsque vous modularisez votre code existant. En g\u00e9n\u00e9rant et en relan\u00e7ant des tests unitaires sur des applications ” back-end ” au fur et \u00e0 mesure que vous les modifiez, vous vous assurez que les d\u00e9ploiements pr\u00e9c\u00e9dents fonctionnent toujours lorsqu’ils sont combin\u00e9s \u00e0 de nouvelles fonctionnalit\u00e9s.<\/p>\n
Ce type de technique de “Test Driven Maintenance” (TDM) permet d’effectuer des tests unitaires \u00e0 la demande et par lots,<\/b> comme une sorte de syst\u00e8me d’alerte pr\u00e9coce pour emp\u00eacher l’apparition de r\u00e9gressions lorsque vous “d\u00e9m\u00ealez” votre ancien code.<\/p>\n
Pour \u00eatre pleinement adopt\u00e9e par les d\u00e9veloppeurs, toute fonctionnalit\u00e9 de test unitaire sur IBM i doit \u00eatre int\u00e9gr\u00e9e dans l’environnement de d\u00e9veloppement RDi, et aussi avec des outils standards tels que Jenkins et JUnit pour encourager le partage des outils entre les \u00e9quipes multi-technologiques.<\/b> Les meilleures solutions de tests unitaires sur IBM i peuvent automatiser \u00e0 la fois la cr\u00e9ation et l’ex\u00e9cution des cas de test, en utilisant la technologie d’analyse syntaxique pour rechercher les param\u00e8tres et leurs types de donn\u00e9es et identifier rapidement toutes les entr\u00e9es et sorties du programme test\u00e9. La connaissance des r\u00e9f\u00e9rences crois\u00e9es et des d\u00e9pendances permet \u00e9galement de g\u00e9rer les cas de test et de r\u00e9utiliser les cas entre les versions.<\/p>\n<\/p>\n
<\/div>\n6. L’importance de l’automatisation des tests sur IBM i<\/strong><\/h2>\n
Il existe encore quelques cas extr\u00eames o\u00f9 les applications IBM i ne peuvent pas \u00eatre facilement remani\u00e9es et o\u00f9 le co\u00fbt\/temps de restructuration du code est prohibitif.<\/p>\n
Dans ce cas, l’automatisation des tests fonctionnels est la meilleure option. Les cas de test sont cr\u00e9\u00e9s automatiquement lorsque les utilisateurs ex\u00e9cutent les fonctions de l’application \u00e0 partir de l’interface utilisateur standard. Contrairement aux tests unitaires o\u00f9 l’environnement de donn\u00e9es sous-jacent est dynamique, les donn\u00e9es de test fonctionnel sont statiques et restaur\u00e9es avant chaque ex\u00e9cution de test afin de d\u00e9tecter les r\u00e9gressions par simple comparaison des donn\u00e9es, sortie spool et interface utilisateur. Il n’y a pas de notion de succ\u00e8s ou d’\u00e9chec, seulement des diff\u00e9rences<\/em>.<\/p>\n
<\/p>\nBien s\u00fbr, une strat\u00e9gie de test optimale combine \u00e0 la fois une automatisation des tests unitaires et des tests fonctionnels pour minimiser le temps moyen de r\u00e9paration (MTTR) des d\u00e9fauts dans leur ensemble. La r\u00e9utilisation et le partage des cas de test \u00e9vitent une perte de temps co\u00fbteuse pour le d\u00e9veloppeur et font des tests une activit\u00e9 continue, partie int\u00e9grante du cycle global CI\/CD.<\/p>\n<\/p>\n
<\/div>\n7. Garantir l’adoption des tests unitaires par les d\u00e9veloppeurs<\/strong><\/h2>\n
En conclusion, nous avons vu que les tests unitaires facilitent un style de test \u00ab bottom-up \u00bb, en validant les parties individuelles d’un programme avant de tester la “somme de ses parties” <\/b>– une approche qui anticipe les d\u00e9fauts restants et r\u00e9duit l’effort des tests d’int\u00e9gration ult\u00e9rieurs.<\/p>\n
Les tests unitaires agissent comme une sorte de “documentation vivante” du syst\u00e8me, permettant une compr\u00e9hension rapide de l’interface d’une unit\u00e9. Dans le cas d’un \u00ab Test Driven Development \u00bb, ils peuvent m\u00eame remplacer une sp\u00e9cification d\u00e9taill\u00e9e.<\/p>\n
Cependant, les tests unitaires doivent \u00eatre effectu\u00e9s en parall\u00e8le avec d’autres formes de tests, car ils ne permettent pas de d\u00e9tecter les erreurs au niveau du syst\u00e8me ou les erreurs fonctionnelles, ni les aspects non fonctionnels tels que les performances.<\/p>\n
Le principal d\u00e9fi des tests unitaires est la cr\u00e9ation de tests r\u00e9alistes et utiles<\/b>, afin d’\u00e9tablir les conditions initiales pertinentes qui refl\u00e8tent l’ex\u00e9cution normale d’une application. Plus important encore, les tests unitaires doivent \u00eatre maintenus en parall\u00e8le avec le processus de changement d’application lui-m\u00eame, afin de garantir que les tests impact\u00e9s soient maintenus \u00e0 jour et ex\u00e9cut\u00e9s pour chaque changement de code d\u00e9pendant. Pour faciliter la maintenance des tests unitaires, il doit \u00eatre facile de r\u00e9-identifier les nouveaux champs d’entr\u00e9e et de sortie \u00e0 mesure que l’application \u00e9volue.<\/b> Sinon, les tests unitaires peuvent devenir aussi bogu\u00e9s que le code qu’ils sont cens\u00e9s tester !<\/p>\n
Pour surmonter ces difficult\u00e9s, les tests unitaires doivent \u00eatre hautement automatis\u00e9s et faire partie int\u00e9grante du cycle de livraison continu :<\/b><\/p>\n
- \n
- D\u00e9tection automatique des entr\u00e9es et des sorties pour automatiser la cr\u00e9ation de tests r\u00e9alistes\/utiles<\/li>\n
- Int\u00e9gration des tests unitaires dans le processus de contr\u00f4le de version<\/li>\n
- Auto-ex\u00e9cutions des tests en tant que partie continue du flux CI\/CD<\/li>\n
- R\u00e9utilisation des actifs des tests unitaires pour chaque changement de programme<\/li>\n
- Maintenance\/mise \u00e0 jour des tests unitaires en fonction des d\u00e9pendances<\/li>\n<\/ul>\n
En r\u00e9sum\u00e9, les essais unitaires sont tr\u00e8s b\u00e9n\u00e9fiques mais imposent une certaine rigueur, n\u00e9cessitant une automatisation maximale pour une adoption \u00e0 long terme !<\/p>\n
8. La diff\u00e9rence avec Arcad i unit<\/strong><\/h2>\n
ARCAD iUnit<\/a> a \u00e9t\u00e9 con\u00e7u pour maximiser l’automatisation tout au long du processus de test unitaire sur IBM i. En tant que tel, il peut m\u00eame \u00eatre utilis\u00e9 par des d\u00e9veloppeurs qui ont peu ou pas de connaissances de l’application \u00e0 tester.<\/p>\n
Tout ce dont ARCAD iUnit a besoin pour commencer \u00e0 travailler est un nom de biblioth\u00e8que. Il en d\u00e9coule un r\u00e9f\u00e9rentiel de connaissances sur les objets contenus dans la biblioth\u00e8que, utilis\u00e9 pour aider le d\u00e9veloppeur \u00e0 chaque \u00e9tape du processus.<\/p>\n
Une fois qu’ARCAD iUnit a analys\u00e9 le contenu de la biblioth\u00e8que, l’outil guide le d\u00e9veloppeur dans la cr\u00e9ation et l’ex\u00e9cution des tests \u00e0 partir d’une interface graphique facile \u00e0 utiliser. Toutes les t\u00e2ches les plus fastidieuses sont enti\u00e8rement automatis\u00e9es, telles que :<\/b><\/p>\n
- \n
- l’identification de toutes les proc\u00e9dures d’un programme et de leurs param\u00e8tres d’entr\u00e9e\/sortie<\/li>\n
- la d\u00e9finition des r\u00e9sultats attendus<\/li>\n
- obtention\/r\u00e9glage de valeurs<\/li>\n
- marquage\/suivi des variables<\/li>\n
- ex\u00e9cution des tests – individuellement ou en tant que suite<\/li>\n
- exportation de tests vers JUnit<\/li>\n
- ‘mocking’ de base de donn\u00e9es, pour injecter des donn\u00e9es dans une table avant l’ex\u00e9cution du test<\/li>\n
- ‘mocking’ d’un programme, pour changer le comportement par d\u00e9faut du programme<\/li>\n
- ex\u00e9cution de projet “libre”, pour g\u00e9rer les programmes manquants<\/li>\n
- int\u00e9gration avec plusieurs outils d’automatisation : Jenkins, Azure Pipelines, CloudBees, GitLab CI…<\/li>\n<\/ul>\n
L’introduction de ce niveau d’automatisation fait avancer le d\u00e9veloppement d’applications IBM i dans le monde DevOps “continu” qui est caract\u00e9ristique sur les syst\u00e8mes distribu\u00e9s – avec tous les avantages que cela apporte en termes de fiabilit\u00e9 de l’application, de retour sur investissement, d’\u00e9limination de la dette technique ou encore de continuit\u00e9 de l’activit\u00e9 pour en nommer quelques-uns.<\/p>\n
9. Conclusion<\/strong><\/h2>\n
En bref, les tests unitaires sont un maillon indispensable et souvent manquant du d\u00e9veloppement logiciel sur IBM i.<\/p>\n
Les tests unitaires automatis\u00e9s peuvent rendre un pipeline DevSecOps sur IBM i v\u00e9ritablement continu<\/b> – avec des avantages mesurables en termes de qualit\u00e9, de vitesse et de co\u00fbt.<\/p>\n
Pourtant, l’adoption des tests unitaires et le taux de retour d\u00e9pendent du degr\u00e9 d’automatisation offert par l’outil de test unitaire. Pour obtenir un portail de qualit\u00e9 s\u00e9curis\u00e9, seuls les outils capables de d\u00e9charger TOUTES les t\u00e2ches de cr\u00e9ation de tests de routine du d\u00e9veloppeur avec suffisamment de flexibilit\u00e9 pour s’adapter \u00e0 un environnement changeant, seront adopt\u00e9s \u00e0 long terme. En ce qui concerne l’IBM i, ARCAD iUnit<\/a> apporte un niveau d’automatisation sans pr\u00e9c\u00e9dent et un ROI prouv\u00e9, quelle que soit la variante de langage utilis\u00e9e.<\/p>\n<\/div><\/div><\/div>
![\"Olenka](\"https:\/\/www.arcadsoftware.fr\/arcad\/wp-content\/uploads\/2026\/03\/olenka-van-schendel.png\" "\\"olenka-van-schendel\\"")
<\/span><\/div><\/div><\/div>