Bonjour,

Avec les récentes versions de NetWeaver, SAP propose des outils de tests unitaires. Dans cet article, je vais revenir brièvement sur la définition des tests unitaires, leur utilité et leur intégration dans les développements ABAP.

La base

Un test unitaire est un test permettant de vérifier le bon fonctionnement d’une unité de développement, à savoir une méthode (dans le cadre OO, mais cela peut être un sous-programme, un module fonction [s’il est simple {mais n’oublions pas qu’il faut développer en orienté objet !}]).
Idéalement, il faudrait développer en utilisant le TDD. Le Test-Driven Development, c’est (en très gros) rédiger son test unitaire, tester (le résultat du test est un gros KO), puis rédiger le code qui permet de passer le test avec succès.
Un petit exemple, le micro besoin est de faire une division, donc je rédige mon test qui va appeler la méthode de division avec deux valeurs fixées en dur dans le test, puis va comparer le résultat de la méthode avec le résultat attendu. La première étape est « la méthode de division n’existe pas ». Alors on crée la méthode vide. On ré-exécute le test qui sera toujours KO car le résultat ne sera pas le bon, et ainsi de suite jusqu’à obtention du bon résultat.
L’idée finale est que la lecture des tests unitaires permette de comprendre ce que fait le code (dans notre exemple, on aura donc un test de division, mais il faudra également un test de division par zéro).

Dans SAP

Pour tout cela, SAP a créé des outils qui permettent de faciliter les tests unitaires. On peut donc créer des classes de tests unitaires. Exemple, je crée une classe globale de calculatrice et à l’intérieur de cette classe, j’implémente ma classe locale de tests unitaires qui contiendra une méthode DIVIDE_BY_ZERO, entre autres.
Ensuite, via un clic ou deux, ou un simple raccourci-clavier, le système va exécuter toutes les méthodes de test et affiche le résultat des tests unitaires. Il est de plus possible d’automatiser l’exécution de ces tests unitaires lors de la libération d’un ordre de transport.

Pour finir, rappelons que l’idée des tests unitaires est simplement de tester chaque ligne du code. Aussi, SAP fournit également un outil qui va contrôler le pourcentage de code qui est testé par les tests unitaires.
Je reprends l’exemple de la méthode de division. Mettons que cette méthode contiennent en gros un IF qui vérifie que l’on ne divise pas par zéro. Et supposons que nous n’ayons qu’une seule méthode de test unitaire qui se contente de tester la division de 10 par 5. Dans ce cas, l’analyse de la couverture du code testé unitaire remontera une alerte pour indiquer que le test unitaire ne passe pas dans la branche « division par zéro » du code ABAP testé.

Notons en outre que tout ceci est désormais intégré dans Eclipse, ce qui est une très bonne nouvelle. Donc… mettez à jour vos systèmes !

L’ABAP Test Cockpit

SAP fournit aujourd’hui l’ABAP Test Cockpit (ATC). Un framework pour exécuter des contrôles statiques du code pour découvrir les problèmes fonctionnels, d’utilisabilité, de performance ou de sécurité. Dans les faits, les contrôles sont basés sur le Code Inspector et le framework propose plus de fonctionnalités. Via la transaction SE80, on peut accéder à l’ATC Result Browser qui va afficher l’ensemble des erreurs remontés par le Code Inspector. Chaque erreur est affectée à une personne de contact (généralement le développeur responsable de l’objet en cause).
Cette personne peut visualiser l’erreur et décider de la corriger ou bien elle peut demander une dérogation. Par exemple s’il s’agit d’un code trop ancien pour être modifié simplement, ou alors il peut s’agir d’un faux positif. Dans ce cas, la dérogation doit être motivée. Elle est automatiquement affectée à un responsable qualité, pour respecter le « four-exe principle », soit un contrôle par deux personnes au lieu d’une seule.
Celui-ci peut accéder à cette dérogation et décider de l’accepter ou non.

Conclusion

D’après mon expérience, beaucoup de développeurs (et pas seulement ABAP) vont au plus vite. On pisse du code, c’est rapidement livré et ça fonctionne la plupart du temps. Quick and dirty. En parallèle, les méthodes de développement évoluent. L’orienté-objet dans SAP, dans les codes spécifiques, est encore relativement rare. De fait, lorsqu’une erreur est découverte dans un programme ancien, ou qu’une évolution est nécessaire, qui ne s’est jamais arraché les cheveux pour essayer de faire le moins de dégâts possibles ? La solution à ce problème est simple en apparence : que chacun produise un code de qualité et testable à volonté. En effet, il suffirait d’exécuter un test avant et après l’implémentation d’une correction ou d’une évolution pour s’assurer que l’on n’a rien cassé. Mais en pratique, ce n’est pas si facile sans un cadre adapté à une telle approche.
Mais on le voit, SAP fait de gros efforts pour permettre à chaque développeur de produire un code propre et qui fonctionne (on ne parle pas ici de l’adéquation du fonctionnement du code par rapport aux besoins métiers, mais bien du fait que le code se comporte tel que le développeur l’a voulu). Cependant tous ces outils ne servent à rien sans une réelle démarche de qualité au sein de l’équipe de développement, voire même en amont. La problématique sous-jacente est donc humaine : il faut changer les comportements et sensibiliser tout développeur à la qualité du code livré. En un mot, professionnaliser le développeur.