Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

“Notre boulot est de vous dire que votre bébé est laid.” - Software Testers

Il paraît évident que tester est une pratique essentielle afin de valider la qualité d’un produit. Ainsi, vous gagnerez à incorporer des tests à votre application dans l’optique de vérifier son bon fonctionnement. Mais cela peut vite devenir une corvée pour beaucoup de développeurs. Sans une vraie méthodologie, les développeurs testent souvent pour tester, parce que le projet le demande. Dans ces cas-là, malheureusement, les tests deviennent un fardeau qu’il faut traîner tout au long du développement de notre application.

Ce n’est pourtant pas toujours le cas et une suite de tests peut même être un outil très puissant. Alors pourquoi cette vision n’est-elle pas celle de tous ? Souvent, on observe un manque de rigueur dans la mise en application des méthodologies de testing voire même une stratégie de tests complètement inexistante. L’une de ces méthodologies est appelée TDD (Test-Driven Development) ce qui veut dire littéralement : le développement guidé par les tests.

Qu’est-ce que le TDD exactement ?

Recommandée par Google et de célèbres développeurs comme Robert Cecil Martin (plus connu sous le surnom de Uncle Bob) tout comme IBM ou Microsoft, cette méthodologie consiste à écrire le test avant le code ; tout est là ! De cette façon, les tests mis en place en amont vont conduire le développeur à bien écrire le code de l’application. Pour en formaliser les principes, trois “lois” ont été édictées par Robert C. Martin :

1. Tu n’écriras pas de code tant que tu n’auras pas écrit un test qui échoue
2. Tu n’écriras pas plus de tests que nécessaire pour en faire échouer un. Et les échecs de compilation sont des échecs comme les autres
3. Tu n’écriras pas plus de code qu’il n’en faut pour faire passer le test qui a dernièrement échouée

En appliquant ces trois règles, vous entrez dans un cercle vertueux alliant qualité et absence [totale ou presque] d’anomalies.

Au final, le code de tests et le code de production sont écrits ensemble et en parallèle tout au long du projet avec une petite avance pour le code de tests de quelques dizaines de secondes. C’est pourquoi, si ces règles sont scrupuleusement suivies, la couverture de code sera à 100%. Mais le TDD réserve d’autres avantages.

Les intérêts du TDD

Sans surprise, le TDD vous assure que votre code fonctionne comme vous l’aviez imaginé et implémente les fonctionnalités requises. Les tests guident le développement de l’application et le TDD assure la qualité.

Le TDD permet le changement. Habituellement, les développeurs ont, à juste titre, peur des changements. Pourquoi ? Car chaque changement est une anomalie potentielle qui peut mener vers une régression. Avec le TDD, les tests sont régulièrement et fréquemment exécutés. Donc vous êtes rapidement notifié si une modification, réorganisation ou un ajout dans votre code a créé une anomalie. Les tests deviennent votre filet de sécurité.

Cela facilite le façonnage d’un code propre et optimisé. En effet, la sécurité fournit par le TDD, prévenant la régression, nous donne la possibilité de nettoyer et améliorer sereinement notre code. Pour les puristes du TDD il s’agit même là de son atout premier.

En plus, les tests étant écrits avant le code de production, cela vous force à réfléchir en amont à comment vous aimeriez utiliser le code que vous êtes sur le point de créer. Vous allez devoir à l’avance penser au design de ce dernier et faire des choix comme le nom des classes, des méthodes ou encore des attributs. Une fois de plus, le code propre est mis en avant avec le TDD.

Enfin, cette méthodologie encadre le développeur en lui permettant de se concentrer uniquement sur la partie de la fonctionnalité sur laquelle il travaille. Comment ? Et bien, une fois le test écrit, le seul objectif du développeur est de faire passer le test, ni plus ni moins et ce peu importe la manière. Ce n’est que dans un second temps qu’il améliorera son programme.

Prévenir plutôt que guérir

Concernant la quantité d’anomalies (bogues) en production, le TDD peut aisément la réduire de 40 à 70%. Les anomalies sont en plus détectées plus tôt dans la phase de développement. Et le plus tôt le mieux parce que le temps qu’une anomalie soit repérée, l’application continue à être développée dessus. In fine, plus tard nous corrigerons le problème plus il sera difficile de creuser dans le code afin de le trouver et le résoudre.

Concrètement, corriger une anomalie en phase d’implémentation est 16 fois plus rapide que de le faire lorsque l’application est déjà en production. Donc plutôt que de gaspiller 2 jours pour corriger un bogue, le développeur qui aura judicieusement choisi l’approche TDD n’y passera qu’une heure.

Le fruit d’une pratique correcte du TDD

Si nous avons vu des avantages majeurs, il faut aussi prendre en considération certains points de vigilance. Avant toute chose, étant donné que le code des tests est proche du code de production en termes de densité, il est essentiel de le garder propre. Pourquoi ? Car tout comme le code de production, le code des tests doit lui aussi être maintenu pour rester lisible. Avec le TDD, il devrait être plus facile de modifier les spécifications d’une fonctionnalité et donc, plus facile de modifier les tests. Il est donc fondamental d’avoir un code de production propre et un code de tests propre.

“Les tests ne sont pas des citoyens de second plan.” - Robert C. Martin

Mais le TDD et les tests ne font pas toujours l’unanimité accusés, souvent à tort, de faire perdre du temps. Il est vrai qu’une application sera développée plus vite sans TDD, mais ce n’est sans compter le nombre de bogues et d’anomalies avec lesquels elle sera publiée. Et finalement le temps que les développeurs passeront à corriger ces problèmes pourra se révéler accru. Finalement le TDD qui, prévient ces anomalies (jusqu’à 90% en moins !), réduit le temps de résolution des bogues, et offre une capacité à changer sereinement, devrait être considéré comme un gagne-temps efficace.

Le vrai coût à considérer en amont est celui de la formation des développeurs à maîtriser la méthodologie. Une fois que cela est fait, le TDD fera sans l’ombre d’un doute économiser du temps, des cheveux blancs et de l’argent.