Les approches TDD (Test Driven Developpement) et ATDD (Acceptente Test Driven Developpement) sont des outils que toute organisation souhaitant se tourner vers les méthodologies Agiles (Scrum/Kanban/Lean/Itil/…) devraient utiliser.
C’est une approche qui est très bien documentée et il existe de nombreuses formations qu’on peut suivre et qui vont vous expliquer l’art et la science sur le comment faire des tests automatisés lors du développement de vos logiciels.
Au fil des années, j’ai vu plusieurs organisations qui ont voulu se lancer en lisant cette documentation et en envoyant leurs ressources faire des formations. Elles ont aussi investis beaucoup de temps à mettre en place des outils tel que NUnit, Ms-Tests ou JUnit (ou autre framework de tests)… sans atteindre le ROI recherché.
La conséquence directe : Arrêt du TDD car le profit n’est plus identifié.
La transformation n’est pas simple
En informatique comme dans la vie, il faut bien se préparer. Même si l’approche est bien documentée, je le reconfirme, il faut mettre en place des choses, voir faire des ajustements dans vos environnements avant d’ajouter cette suite d’outils dans votre arsenal.
Pour l’exemple, imaginons que vous utilisiez toujours le langage Cobol dans un environnement central. Du jour au lendemain, vous décidez de passer à un environnement Web comme ASP.NET. Il ne suffira pas de former vos ressources : Elles devront apprendre une toute nouvelle manière de programmer. De plus, vos architectes devront aussi penser différemment leurs design d’applications…
C’est la même chose, lorsqu’on souhaite se lancer dans les approches de type TDD. Il y a des devoirs à faire. Il faut aussi apprendre à nos programmeurs à faire des tests. Toutes les formes de tests et pas seulement ceux automatisés. Car, avant de faire des tests automatisés, il faut savoir bien tester et surtout savoir qu’est-ce que c’est “un test”.
Ils devront ré-apprendre à programmeur leurs classes, leurs fonctions. Autrement dit, revenir à la base des techniques de programmation. Car, un vrai test, ça doit tester une seule chose. Et dans nos livres d’initiation à l’université, une fonction devait aussi faire une seule chose.
Donc il faut être extrêmement méthodique afin de mettre en place les TDDs.
Par ailleurs, il faut plusieurs heures de travail, pour automatiser la création du test et je ne parle du grand nombre des lignes de code qu’on doit écrire.
Quelle méthodologie d’accompagnement ?
Bravo, vous avez décidé de poursuivre ! Mais, vous voulez savoir comment on fait ?
La première étape, je crois que vous l’avez fait, c’est-à-dire donner une formation à vos ressources sur l’art du test automatisé. (Vous pouvez toujours contacter Octo qui propose ce genre de formation).
Ensuite, il faut définir le cadre d’utilisation de ce nouvel outil. Ce n’est pas parce que vous avez choisi d’utiliser cette approche qu’il faut l’utiliser partout dans un premier temps. Je recommande d’abord de le faire sur un petit projet. Voir peut-être, permettre d’abord seulement à certaines ressources de l’utiliser dans un petit projet ou partie d’un projet. Trop souvent, les organisations veulent faire ce virage en grande vitesse, et ce n’est pas toujours une bonne idée. L’expérience s’acquière avec le temps.
Les tests automatisés ne conviennent pas à tout et pour tout. Vous n’aurez peut-être pas tous les gains d’une intégration complète. Mais, la partie où ils seront utilisés vous apportera d’un premier temps la rentabilité tant recherchée.
En conclusion
Choisir de faire un passage aux tests unitaires automatisés n’est pas une chose simple. Ce choix doit se faire en plusieurs étapes tout comme toutes les transitions vers une méthodologie Agile.
Elle aura des impacts partout dans votre développement logiciel. Mais, si vous persistez et que vous faites les bons choix (stratégie, accompagnement,…). Je crois qu’avec le temps, vous en ferez un succès.
