Bonjour à tous,

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

Les difficultés rencontrées

Initialement, on ne sait pas réellement dans quoi l’on s’embarque, mais il faut signaler que démarrer la pratique du TDD n’est pas aisé et que les équipes Agiles où c’est la norme considèrent qu’il n’est pas facile à apprendre en général.
Dans l’étude du docteur Dobb, Ambler a demandé pourquoi le TDD n’est pas devenu plus répandu.

Donc, pourquoi les gens ne font pas plus de TDD ? Premièrement, le TDD requiert de la discipline et des compétences. Quand on interroge les fonctionnels sur la difficulté du TDD, 39% des sondés répondent que c’est très difficile ou difficile et l’on obtient la même réponse pour 49% des développeurs. L’étude a exploré quatre problèmes potentiels qui pourraient entraver l’adoption du TDD, et ces quatre problèmes ont un impact significatif. Le manque de compétence en TDD a eu l’impact le plus important, suivi de près par l’absence d’une suite de test de régression pour les fonctionnalités déjà existantes. Les deux autres facteurs sont le manque d’entraînement et de formation (qui a un impact direct sur les compétences) et la culture du cycle de vie en cascade.

Ici nous nous attardons sur le développeur TDD, ce qui correspond principalement à l’automatisation des tests unitaires. Les compétences et la discipline requises ne sont pas négligeables. Comme tout ce qui vaut la peine d’être appris, cela prend du temps. Écrire les tests en premier est une pratique si peu familière et naturelle, qu’au début il sera difficile de ne pas retourner aux vieilles habitudes. Même si l’on parvient à se contraindre à écrire d’abord les tests, le code sur lequel on va travailler, qui est probablement du code existant, ne sera pas nécessairement aisément testable.

Le manque de compétence en TDD dans une entreprise est effectivement une barrière à son adoption. Dans certains cas, cela ralentit juste un peu les choses. Cependant, un développeur peu motivé à apprendre de nouvelles techniques peut ne pas avancer à moins qu’il n’y ait un fort antécédent de TDD dans l’entreprise. Si l’on n’a pas un collègue expérimenté qui nous guide, beaucoup de temps sera consacré (perdu ?) à comprendre comment cela fonctionne, beaucoup de frustration et de retours aux mauvaises habitudes ; au début, le TDD demande plus de travail. Le mentorat ou l’entraînement ne doivent pas être sous-estimés. Avec des encouragements et des conseils, on a l’assurance que les efforts vont au final payer.

L’absence de tests de régression est également un grand problème. Il n’y pas d’exemple de classes de tests unitaires, et comme le code n’a pas été testé de cette façon, il n’est pas conçu avec les tests à l’esprit. C’est ici que l’on peut avoir le plus de difficultés à appliquer le TDD, sur du code existant – il n’est pas évident de déterminer la façon de transformer le code existant et c’est là que le soutient d’un expérimenté du TDD est le plus utile.

Enfin, et concernant la culture du cycle de vie en cascade, les développeurs déterminés n’abandonneront pas le TDD même s’ils doivent travailler avec des plannings de cascade. Cependant en général, la culture du cycle de vie en cascade signifie que les méthodes associées à l’Agile sont peu susceptibles d’attirer l’attention.
Cela vaut la peine de lire entièrement l’article Agile Update pour obtenir des ressources sur le TDD et les défis auxquels les équipes de développement Agile font face lors de l’adoption du TDD. Si une équipe de développement Agile trouve cela difficile, cela le sera encore plus pour le développeur ABAP classique, qui travaille habituellement seul et n’est pas habitué à faire autrement.

J’arrête ici ce second article de traduction. Le tableau peint n’est pas des plus réjouissants. En effet, on semble conclure qu’il est très difficile de se mettre au TDD en ABAP si l’on ne dispose pas d’une bonne culture des méthodes Agile, ou du moins si l’on n’a pas un collègue qui lui possède une telle culture. Espérons que les prochains articles, qui traiteront de la façon d’écrire les tests et de la limitation induite par les outils ABAP, apporterons un peu de positif dans tout cela !