Par Olenka Van Schendel | 19 mai 2020

Sur les systèmes modernes et distribués, les tests unitaires sont sans doute l’élément le plus efficace de votre stratégie de test. Une batterie de tests unitaires bien conçus « impose » la qualité de votre application au fur et à mesure de son développement – et idéalement même avant.  Les éléments des tests unitaires sont ensuite réutilisés en continu pendant toute la durée de vie de l’application afin de détecter toute régression dans le système.

Mais comment les tests unitaires peuvent-ils profiter aux applications existantes sur IBM i – et en particulier à celles qui n’ont pas été conçues dans une optique « unitaire », et où le code monolithique a toujours été la norme ?

Dans cet article, nous examinerons l’importance des tests unitaires en général et évaluerons la pertinence de cette technique sur IBM i.

1. La qualité à partir de la quantité

Les tests unitaires sont souvent négligés au profit de techniques plus orientées « business » comme les tests fonctionnels ou de bout en bout.  Les tests unitaires prennent un temps précieux aux développeurs, surtout sur une base de code ancien comme IBM i qui n’est pas particulièrement structuré en « unités ».  Alors comment un test unitaire par « boîte blanche », sans connaissance des fonctionnalités réelles de l’application, peut-il sauvegarder la qualité et la précision de votre système, sans parler de la réduction de vos coûts de développement ?

La solution réside dans la quantité et la couverture des tests.

Les