Le test-driven development (TDD) : avantages et 3 étapes à suivre

Le test-driven development est une méthode de plus en plus privilégiée pour s'assurer de la qualité d'un logiciel. Elle est d'ailleurs souvent citée dans les bonnes pratiques de développement, bien qu'elle reste peu utilisée par les équipes de développement. Voici les avantages du développement piloté par les tests et les étapes à suivre pour la mettre en place.

À l'origine du TDD, il y avait le test first design qui consistait à écrire les tests avant de coder. Cette approche a été développée par un développeur de logiciels américain, Kent Beck, aussi fondateur de l'extreme programming. Le principe est simple : au lieu de commencer par écrire un code source, puis de le tester, les développeurs commencent par écrire le test. Les tests sont utilisés pour écrire et intégrer le meilleur code possible.

La méthode a ensuite évolué pour donner : pour chaque ligne de test en échec, une ligne de code de production est écrite pour réussir le test.

Pourquoi faire du TDD ?

Le test-driven development s'effectue par cycle de trois phases : red (rouge), green (vert) et refactor (remaniement).

Cette procédure cyclique permet de s'assurer que le code transféré au système de production répond aux attentes. Elle permet d'enrichir le logiciel de nouvelles fonctions puisqu'un nouveau code source est écrit après chaque test réussi.

L'intérêt du TDD est d'explorer le besoin, de le préciser et de spécifier le comportement du logiciel voulu selon son utilisation, et ce, avant chaque étape du codage. Ainsi, le logiciel produit est pensé pour répondre précisément au besoin et est conçu pour le faire avec simplicité.

En se servant de la méthode du test-driven development, le logiciel devient plus fiable, mieux conçu et de meilleure qualité.

Écrire les tests en amont du code permettent de guider de corriger un problème en guidant le codage à chaque étape. Cela permet aussi de documenter le comportement du logiciel et d'obtenir un filet de sécurité contre les régressions.

1 - Écrire un test unitaire qui échoue

La première étape de la méthode du test-driven development consiste à développer un test qui échoue volontairement. L'échec est normal, puisque les développeurs ont créé des tests compacts basés sur des hypothèses. Autrement dit, comme le code à tester n'a pas encore été créé, le test va forcément conduire à l'échec. Le test unitaire est donc symbolisé par la phase rouge.

2 - Réécrire le code pour réussir le test

L'idée de cette seconde étape est de passer le test avec le minimum de code et le minimum d'effort pour répondre au besoin. Pour cela, l'équipe de développement doit apporter les modifications minimales nécessaires pour corriger le code afin qu'il s'exécute correctement. Le test va donc devenir un succès et passer au vert.

3 - Remanier le code

La dernière étape, celle du refactoring, permet de remanier le code pour contrôler que tous les tests réalisés restent bien en vert.

Dans cette phase de cycle, l'équipe de développement a besoin de structurer et de potentiellement compléter le code de production afin qu'il soit propre et lisible.

Afin d'être le plus efficace possible, il est conseillé d'adopter le point de vue d'une tierce personne découvrant le code et se demander s'il est suffisamment compréhensible pour elle.

Quels sont les avantages du TDD ?

Limiter les bugs

Le principal avantage du test-driven development est la diminution significative des erreurs de codage dans le développement d'un logiciel. Le fait de passer les tests obligent les équipes de développement à être rigoureuses et vigilantes.

Lorsque un test échoue alors qu'il passait, permet de détecter une régression, qui peut tout de suite être corrigée. Refactoriser en permanence le code permet d'avoir une amélioration du code et un produit final d'une plus grande qualité.

Avoir un code optimisé

Le TDD présente l'avantage d'augmenter sa confiance dans le code. Il permet d'obtenir un code plus optimisé grâce au remaniement constant, et de surcroît un logiciel mieux conçu. Le fait d'écrire les tests avant le code permet aux développeurs d'affiner la conception du code objet. Le code est de meilleure qualité et chaque partie est moins dépendante des autres.

Le test-driven development permet de lever la peur de refactorer. Comme le code est optimisé, les développeurs craignent moins de détériorer le projet en faisant des modifications ultérieures.

Gagner en productivité

Un autre atout du TDD est le gain en productivité des équipes de développement. Cela permet d'optimiser le temps passer à la correction de bugs et de le consacrer à la création du code en production.

Bien que la conception, la création des tests et leur exécution requiert du temps, il est vite compensé par le temps gagné en tests et en vérifications à la fin du projet web.

Plus un problème est détecté tôt dans les phases de développement, moins le temps passé à sa correction sera important. Le développeur gagne en productivité et développe une base de code plus flexible. Par conséquent, les coûts sont également réduits.

Obtenir une documentation automatique

Les tests écrits pour les fonctionnalités de l'application peuvent servir de documentation automatique pour l'ensemble de l'application. Ils permettent de mieux comprendre comment elle est censée fonctionner. Le TDD permet donc une meilleure couverture du code.

Les limites du test-driven development

Même si le test-driven development présente de multiples avantages, il comporte aussi des limites.

Le TDD nécessite beaucoup de temps pour son implémentation : l'écriture des tests à l'avance peut induire que le projet mettra plus de temps à se lancer. Lorsque le projet n'est pas bien cadré, le TDD peut devenir coûteux en matière d'argent et de temps.

Cela peut aussi être le cas si les fonctionnalités attendues changent en cours de route. Les anciens tests deviennent obsolètes et les développeurs devront y consacrer plus de temps qu'en utilisant une méthode de développement traditionnelle.

Par ailleurs, la méthodologie du test-driven development peut être complexe à comprendre et à prendre en main. Elle peut exiger une période de formation plus longue.

Mais aussi, la méthode du TDD teste l'exactitude du code et non la facilité d'utilisation du logiciel.

Les inconvénients du TDD proviennent surtout de la nature des projets et de leur cadre de développement. Il est conseillé de l'utiliser pour des applications où les entrées et sorties sont clairement déterminées. Il n'est pas préconisé pour des applications existantes ou ayant une configuration complexe.

Pour aller plus loin, découvrez les opportunités d'affaires liées aux évolutions du web en téléchargeant le guide et la checklist ultime du web 3.0, ou découvrez le logiciel marketing de HubSpot.