Bonjour à tous,

Cet article est la suite du précédent qui poursuivait cette série consacrée au TDD avec l’ABAP.

Dans cette suite de l’article traduit, l’auteur aborde sa propre expérience. Il utilise donc le « je ». Je tenais à rappeler qu’il ne s’agit pas de moi.

Premier aperçu de l’idée de tests unitaires automatisés

Donc, qu’en a-t-il été pour moi ? Mon introduction aux tests unitaires automatisés a démarré avec quelques conseils d’un collègue chef de projet qui avait travaillé sur d’autres projets variés et connaissait quelque peu les méthodes Agile et l’utilisation des tests unitaires automatisés. J’avais déjà entendu parler de l’Extreme Programmging (XP), mais seulement dans le fait qu’il mettait l’accent sur des sessions de programmation à deux (pair programming) durant le développement. Nous avions un exemplaire de « Extreme Programming Explained » au bureau, et après avoir lu quelques idées sur les objectifs impliqués dans l’automatisation des tests unitaires, j’étais intrigué mais je ne savais pas comment l’appréhender.

Peut-être que la difficulté la plus évidente que j’ai rencontrée était qu’il n’y avait aucun développeur ABAP à qui demander des conseils. Il n’y avait personne qui aurait pu s’assoir avec moi et me montrer des exemples, ou faire du pair programming sur un problème pour me montrer. Tel que je le comprends maintenant, seul un développeur avec une expérience significative du TDD pourra être capable de regarder un problème de programmation et savoir instinctivement où commencer, en particulier si l’on travaille avec du code qui n’a encore aucun test.

J’étais vraiment le pionnier du TDD, et l’apparent intérêt de la communauté SDN n’était pas très encourageant. Sur SDN, il y a deux pages wiki et quelques articles de blog. Suffisamment pour démarrer, mais certainement pas le niveau discussion qu’il devrait y avoir. La plupart de ce que j’ai appris sur le TDD à un niveau plus élevé, l’a été par mes propres explorations ou sources à l’extérieur du monde ABAP.

D’abord, j’ai joué un peu avec l’ABAP Unit en tant qu’outil, sans comprendre comment il devait être utilisé. J’ai compris les bases de la création de classes locales de test et l’exécution des méthodes de test. Initialement, cela ressemblait juste à une façon simple d’exécuter des méthodes de classes sans avoir à créer rapidement un programme de tests. Initialement, j’ai utilisé l’outil de test pour exécuter des parties de code tout en debugant pour analyser ce qu’il se passait. Cependant, je ratais le point important de cet outil, parce que je n’avais pas réellement automatisé les tests.

L’ABAP Unit fournit une class appelée CL_AUNIT_ASSERT qui possède des méthodes pour comparer les valeurs de variables avec celles attendues, par exemple ASSERT_EQUALS teste si la valeur attendue et celle réelle sont les mêmes. Si une condition n’est pas satisfaite, nous obtenons un rapport dans la vue de résultat de l’ABAP Unit. Sans utiliser la classe d’assertion, j’avais simplement rendue plus aisé l’exécution des tests unitaires à un stade plus précoce du développement, où ces unités de code n’étaient pas encore incorporées dans l’application. Si l’on ne code aucun test, l’ABAP Unit ne peut que rapporter les problèmes sérieux levant une exception.

En regardant en arrière, il s’agit du problème de démarrer quelque chose sans aucune idée de où commencer, ou bien cela a pu être une tendance à vouloir comprendre les choses.

Comment est-ce que j’écris des tests ?

Je n’ai pas obtenu un grand bénéfice de l’ABAP Unit jusqu’à ce que je lise Test Driven Development: By Example de Kent Beck, qui est à l’origine du framework de tests unitaires dans Smalltalk (sUnit). Ce livre explique la philosophie derrière le TDD, et comment il peut permettre aux développeurs de ne plus craindre la refactorisation du code. J’ai également compris comment il est supposé fonctionné, avec les quatres étapes mentionnées plus haut [ndlr : au tout premier article de cette série].

Une fois que j’eus compris ce que j’essayais de faire, les problèmes inhérents aux tests unitaires dans une application ABAP sont devenus apparants. Les exemples de le livre de Beck n’impliquaient pas de base de données, et habituellement les connexions à la base de données ne font pas partie du test unitaire parce que dans la plupart des environnement de développement on ne peut garantir qu’une base de données sera disponible lors de l’exécution des tests. Parce que l’environnement ABAP dépend de l’existence d’une connexion à la base de données, la connexion est toujours présente et de nombreuses routines dépendent de requête SQL intégrées dans le code de la logique métier.

Les développeurs ABAP ont pris la confortable habitude de disséminer des accès à la base de données identiques un peu partout ; c’est tellement rapide d’écrire des requêtes. Mais cela pose des problèmes quand il s’agit d’écrire des tests. Je travaillais sur beaucoup de codes qui n’étaient pas toujours testable à cause du nombre de dépendances à la base de données, qu’il n’était pas aisé à gérer pour la mise en place du test. De fait, la plupart de mes premiers tests étaient écrits en partant du principe que certaines données étaient présentes dans la base de données. Sans ces données, les tests échoueraient.

J’ai fait quelques tentatives pour pallier ceci en gérant des enregistrements dans la base de données dans un état connu au moment de la préparation du test (setup fixture), puis en les supprimant à la fin du test (teardown). Bien que cela fonctionne, c’est potentiellement risqué et le code de mise en place qu’il faut écrire est fastidieux et chronophage, surtout si plusieurs tables sont impliquées. Je pense que les tests unitaires qui dépendent de la base de données sont quand même intéressants, car il vaut mieux écrire quelques tests plutôt qu’aucun, mais ils ne seront significatifs que pour un seul système SAP et uniquement tant que les données utilisées restent inchangées. Les anciens tests ne seront pas fiables en tant que tests de régression, et cela pourrait demander un effort conséquent de les adapter plusieurs mois plus tard.

La meilleure solution au problème d’accès à la base de données est de refactoriser le code de sorte que tout le SQL soit séparé de la logique métier à tester. Il faut au minimum être capable de renseigner des enregistrements de test dans une routine qui utiliserait des données de la base, bien qu’idéalement il vaut mieux utiliser une classe pour encapsuler le SAL, codée dans une interface qui permette à une implémentation de test ne dépendant pas de la base de données de s’y substituer. Lorsque je parviens effectivement à cette séparation du code SQL et que je travaille simplement avec les données de données ou avec une implémentation test d’accès aux données, la vitesse à laquelle je peux écrire des tests s’accroît considérement.

Ici s’achève cette troisième partie, qui se sera révélée très intéressante à mes yeux, même si elle ne résoud pas vraiment de problèmes. Je crains que cet article ne fournisse aucune réponse précise, mais en tout état de cause, cela montre au moins que le TDD pour l’ABAP reste possible. La suite au prochain épisode !