Bonjour à tous,

Je me propose ici de traduire un article concernant le développement piloté par les tests en ABAP, écrit par Nathan Shepperd. Il s’agit d’un article assez long, aussi aujourd’hui nous n’aborderons que la première partie, qui est une présentation du TDD. La suite traitera de la difficulté de passer au TDD, puis l’auteur exposera sa première approche des tests unitaires automatisés, pour poursuivre sur la façon d’écrire les tests, avant d’explorer rapidement les limitations des outils ABAP. Cela nous fera peut-être trois articles ou plus ici !

Cet article n’a pas pour objectif de décrire l’utilisation de ABAP Unit, c’est plutôt un effort pour exprimer mon expérience personnelle de tentative d’adoption du TTD en tant que l’une des mes pratiques clés en développement. Comme je code actuellement en SAP ABAPm j’ai utilisé ABAP Unit comme un outil pour exécuter des tests, et c’est juste une variante de xUnit, originaire de l’implémentation de Kent Beck dans Smalltalk. Cependant, le framework de tests n’est qu’un élément mineur lorsque l’on s’intéresse au TDD. La pratique change votre processus de développement en profondeur, et ce n’est pas chose aisé d’apprendre à le faire correctement.

Pour commencer, il pourrait être utile que j’explique de quoi il s’agit, car j’espère introduire le concept aux développeurs ABAP qui ne l’ont pas encore croisé, ou ne comprennent pas comment il est censé fonctionner. Le principe du TDD peut être résumé en quatre étapes :

1. Écrire un test pour vérifier qu’une unité de code fait ce qu’elle est supposée faire ;
2. Écrire juste suffisamment de code pour passer le test avec succès ;
3. Immédiatement refactoriser le code sous le test pour supprimer toute duplication ;
4. Répéter les étapes une à trois.

Ceci est souvent confondu avec le Test-First Development, qui n’a pas l’étape trois. Beaucoup de personnes qui diraient pratiquer le TDD font en fait du TFD car elles ne refactorisent pas. L’un des avantages majeurs du TDD est qu’il permet d’améliorer le code et sa conception en refactorisant la solution de base très tôt.

Un point important est que les quatre étapes doivent être un cycle rapide. Le temps passé entre écrire un test et le passer avec succès devrait idéalement être de moins d’une minute, car on n’écrit que le code suffisant à passer le test. Cela implique que le code est divisé en unités qui ne font pas grand chose. Le développeur cherche à s’assurer rapidement que chaque unité de code fonctionne correctement. En outre, les tests unitaires qui en résultent fournissent une spécification de ce que le code est censé faire.

Une fois que l’on a un test passant, on peut refactoriser le code immédiatement tout en étant sûr qu’il reste isofonctionnel. On refactorise tôt pour supprimer tout code superflu qui aurait été ajouté lors de l’étape de passage du test, avec la certitude que les tests vérifieront que le comportement reste identique.

Ce que le TDD cherche à supprimer, c’est la crainte de modifier le code existant, même s’il requiert désespérément une amélioration. Du code fonctionne correctement depuis un certain temps est modifié le moins possible dans la peur que chaque changement puisse être source d’erreur. Souvent cette croyance est renforcée lorsque quelqu’un effectue une modification et casse effectivement quelque chose, entraînant des changements très précautionneux lorsqu’une fonctionnalité est ajoutée ou corrigée. Le problème à long terme est que l’état du code qui est ajouté ou modifié au fil des années se détériore jusqu’à ce que cela soit une corvée de travailler dessus. Ce que nous appellerons l’argument « Mais ça fonctionne ! » tend à persister même si tout le monde est d’accord pour dire que Quelque Chose Doit Être Fait.
Cette crainte vient de l’ignorance. On ne sait pas ce que le programme que l’on modifie fait vraiment, ou bien on a travaillé dessus il y a deux ans et on ne peut tout simplement pas se rappeler des détails de la spécification ou de la dernière chose qui a été faite dessus. L’application de tests automatisés cherche à pallier ce problème en fournissant un mécanisme de régression fiable qui enregistre exactement ce qu’une partie de code est censée faire, et informe si une fonctionnalité a été cassée.

Pour obtenir un peu de perspective sur les bénéfices du monde « Agile », où le TDD est souvent considéré comme une pratique de base pour les développeurs, on peut se référer au travail de Scott Ambler. C’est une personnalité clé du monde Agile. Il a étudié un certain nombre d’équipes Agile et leur a posé des questions sur leur expérience du TDD et les résultats ont été publiés. Il est intéressant de regarder comment les équipes ont évalué les bénéfices obtenus grâce au TDD.

L’étude a exploré les bénéfices que les sondés expérimentaient avec le TDD. Quand il en est venu à l’acceptation du TDD (au niveau des équipes fonctionnelles) les trois principaux avantages ont été une meilleure précision des spécifications, une capacité accrue des développeurs à modifier les logiciels, et une qualité améliorée. Du côté des développeurs, le top trois a été une capacité accrue à modifier les logiciels, une meilleure qualité et une plus grande habileté à réagir aux évolutions des besoins métiers.

Ici nous sommes concernés par le point de vue des développeurs TDD, parce que c’est la raison d’être de l’ABAP Unit. Le dernier point est particulièrement pertinent, car il impacte la capacité d’une équipe à livrer un résultat au client, ce qui est le but premier du développement logiciel.
Ceci étant, bien qu’il est simple de comprendre ce qu’est le TDD, apprendre comment le faire est une chose complètement différente. L’hypothèse ci-dessus est que l’on sait déjà comment écrire les tests qui couvriront une fonctionnalité d’une unité de code. Ce n’est en réalité pas chose facile, comme je l’ai découvert dans mes efforts pour tester le code.

C’est ici que je vais arrêter ma traduction pour cette première partie. La prochaine très rapidement !