Test unitaire sur IBM i

Le test unitaire est une approche de test « boîte blanche » utilisée pour tester l’exactitude d’une « unité » de code isolée. Selon le langage de programmation, une unité peut être un procédé, une fonction, un sous-programme, une méthode ou simplement le plus petit morceau de code qui peut être logiquement isolé dans un système. Les tests unitaires sont généralement effectués par les développeurs et, dans les implémentations DevOps modernes, ils sont considérés comme une partie continue du cycle. Son objectif est de réaliser un « shift left », c’est-à-dire de détecter les défauts à un stade précoce et de réduire ainsi leur coût.
Les tests unitaires fonctionnent en définissant le succès ou l’échec en termes de valeurs de paramètres de sortie attendues pour une entrée donnée. Cette technique d' »auto-validation » fait des tests unitaires un outil idéal pour l’automatisation continue des tests pendant le cycle DevSecOps.

Une fois réussie, une exécution de test est stockée comme référence, et les tests suivants sont évalués par rapport à ce résultat. Cela rend les tests unitaires très efficaces pour détecter les régressions dans le système. Ils peuvent être réutilisés, regroupés et exécutés en tant que partie d’une suite à tout moment, par exemple après chaque construction du système, après un changement d’environnement ou avant qu’un composant particulier ne soit transféré à l’assurance qualité (QA).

Les tests unitaires créés au début de la phase de développement peuvent être utilisés ultérieurement pour un « Smoke Test » d’une application, afin de détecter les erreurs de base avant de perdre du temps à effectuer des tests plus sophistiqués.

Utilisés en continu dans un cycle de CI/CD, les tests unitaires permettent d’identifier précisément les lignes de code où se trouve le défaut. Les bogues sont corrigés avant même qu’ils ne quittent les mains du développeur !

La création de tests unitaires pendant le développement du code améliore la conception du code et le rend plus facile à comprendre par les équipes de développement à l’avenir. En plus d’être plus fiable, le code testé à l’unité est plus simple, plus modulaire et donc plus réutilisable. Cela réduit la dette technique et diminue les coûts de développement à long terme.

Les tests unitaires sont un choix évident pour les langages modernes où le code est structuré en petites unités clairement définies. Mais qu’en est-il des applications RPG et COBOL sur IBM i ?

Les applications IBM i modernes conçues avec une architecture ILE séparent les règles de gestion, la persistance des données et l’interface utilisateur en modules ou fonctions distinctes, ce qui facilite l’automatisation des tests unitaires. Les points d’entrée et de sortie d’un module sont clairs, de sorte que la définition d’un statut « succès/échec » est relativement facile.

Cependant, de nombreuses applications Legacy sur IBM i ont été créées il y a plusieurs décennies et contiennent souvent des blocs de code longs et monolithiques qui n’ont pas été conçus comme des unités. Étonnamment, les tests unitaires ont un très fort retour sur investissement même dans de telles conditions.

Pour être en mesure d’inclure du code monolithique dans votre stratégie de tests unitaires, un certain remaniement est nécessaire. Heureusement, les tests unitaires créent le filet de sécurité dont vous avez besoin pour modulariser votre code existant. En générant et en réexécutant des tests unitaires sur les applications « backend » au fur et à mesure que vous les remaniez, vous vous assurez que les déploiements précédents fonctionnent toujours lorsqu’ils sont combinés à de nouvelles fonctionnalités.