Bonjour à tous,
Cet article va conclure notre série concernant le TDD pour l’ABAP. Au programme de cette traduction : les limitations des outils ABAP, et une conclusion de l’auteur…
Limitations des outils de développement ABAP
Il est vrai que les développeurs, en général, n’aiment pas écrire plus de code qu’il n’est nécessaire, en particulier du code « passe-partout« . Les outils de développement modernes améliore la productivité du programmeur grâce à la complétion automatique des tâches fastidieuses. Ce n’est pas l’un des points forts de l’éditeur ABAP, et concernant le TDD, il y a un générateur de classe de tests pour les classes globales dans NetWeaver 7.0, mais rien pour générer des tests dans des programmes standard ABAP. En outre, il n’y a rien au sujet de l’ajout de méthodes de test. Pour un langage comme l’ABAP, qui requiert la séparation de la déclaration et de l’implémentation, une fonction pour ajouter le corps d’une méthode de test avec sa définition permettrait de gagner du temps et éviterait de naviguer entre les deux parties.
Je me suis rendu compte que cela demande à l’écriture de tests plus de travail que nécessaire. Il est possible de gagner du temps en utilisant des modèles de code définis dans la configuration de l’éditeur ABAP, mais la génération intelligente de code est quelque chose qui manque. Si l’on compare à Java et Eclipse ou IntelliJ Idea, on s’aperçoit combien l’éditeur ABAP est primitif.
Malheureusement, je pense que les développeurs ABAP sont coincés dans cette situation, car il n’y a aucune possibilité d’étendre l’éditeur avec un plug-in ou autre.
Conclusion
L’expérience m’a montré que le TDD peut révéler un nombre important de problèmes dans la façon que l’on a de coder, et cela peut soit entraîner de la frustration, soit amener une opportunité d’apprendre de nouvelles méthodes de développement, et changer ses mauvaises habitudes. De plus, à moins que vous ne puissiez démarrer de zéro, les plus grands défis viendront de l’adaptation du code existant en une forme testable, et cela sera plus difficile si vous n’avez pas d’exemple d’un programme conçu avec le TDD. J’ai trouvé le livre Working Effectively With Legacy Code très utile en tant que guide pour apprendre comment rendre le code existant testable. En fait, il vaut mieux lire ce livre directement après avoir été initié aux concepts du TDD, car c’est avec du code existant que la plupart des développeurs travailleront s’il n’y a aucun historique de la pratique du TDD dans l’équipe.
Cela prend beaucoup de temps, mais finalement on arrive à un point où l’on se rend compte que les tests mis en place facilitent grandement la vie, et que l’on passe beaucoup moins de temps à debuguer. J’ai entendu parler de cela comme le moment « aha », probablement dans une interview de Robert Martin ; quand on se rend soudain compte que ce que l’on vient de faire aurait pris 5, 10 ou 30 minutes sans le TDD.
Finalement, j’ai découvert que le TDD peut transformer une ennuyeuse modification de code en quelque chose d’intéressant, car il y a ce défi de le rendre testable. Cela améliore vraiment ma concentration lorsque je dois traiter des problàmes mineurs qui ne me réjouissent pas au premier abord.
J’ai dans à peine gratté la surface du TDD, mais j’espère que cela pourra encourager d’autres développeurs ABAP à y jeter un oeil et s’y essayer.
Ici s’achève cette traduction.
Conclusion personnelle
J’ajoute quelques mots de mon cru suite à la lecture de cet article. Pour être honnête, je ne l’avais pas lu avant de le traduire. J’étais tombé dessus, l’avais mis dans mes favoris en me promettant de prendre le temps de le lire. Puis je me suis dit que le partager ici serait une bonne idée. Le traduire me force à prendre plus de temps sur le contenu que je ne l’aurais fait avec une lecture rapide en diagonale.
Cet article avait été posté le 22 février 2011, et je me dois donc d’apporter quelques précisions au sujet de l’évolution de l’éditeur ABAP, que l’auteur ne devait pas connaître à l’époque. Certes à ma connaissance l’éditeur ABAP ne dispose toujours pas de génération intelligente de code, cependant, il est désormais possible d’utiliser Eclipse pour développer, donc avec toutes les possibilités offertes par cet IDE.
De plus, nous disposons désormais d’un outil évolué de tests qui permet de vérifier la couverture du code testé (le pourcentage du code couvert par les tests unitaires par rapport à la quantité totale de code). Et les bonnes pratiques, vous le savez si vous suivez ce blog régulièrement, tendent à favoriser de plus en plus l’utilisation du modèle objet, ce qui simplifie l’utilisation de tests unitaires.
Pour m’être un peu essayé aux tests unitaires sous ABAP, je rejoins l’auteur quant à la difficulté de s’y mettre tout seul dans son coin. De nombreuses inconnues se révèlent et l’on ne sait pas comment les résoudre. Un exemple tout simple : comment tester le (bon) comportement d’une méthode privée ? Comment bien écrire et utiliser une interface pour switcher entre une requête dans la base et un fournisseur de contenu « statique » pour le test (qui doit donc être indépendant de la base de données) ? Comment le faire dans un vrai programme et non pas un petit test de division par zéro (exemple vécu !) ?
Lorsque je m’y serais un peu plus familiarisé, je ne manquerai pas de faire un retour d’expérience ici. En attendant, n’hésitez pas à partager la vôtre !