Qu’est-ce que le développement piloté par les tests (TDD) ?

Les développeurs écrivent suffisamment de code pour passer chaque test, puis le test et le code sont affinés avant de passer à un nouveau test, puis à une nouvelle fonctionnalité.

Le développement piloté par les tests oblige essentiellement les développeurs à ralentir, à valider et à affiner leur code dans des cycles de rétroaction plus courts. Bien que cela ne soit pas obligatoire, les équipes DevOps encouragent les codeurs, qu’ils soient novices ou expérimentés, à utiliser le TDD dans un large éventail de langages de programmation tels que Java, Python, les interfaces de programmation des applications (API) et les applications de programmes.

Ce type de programmation renforce la relation entre le codage, les tests (sous forme de tests unitaires automatisés) et la conception du code. Si le développement piloté par les tests peut augmenter le temps de développement initial, il a été démontré qu’il améliore la fonctionnalité et la souplesse du code et permet généralement de gagner du temps.

En identifiant et en corrigeant immédiatement les erreurs, les développeurs qui emploient le TDD peuvent éviter que de petits problèmes ne grandissent. Le développement piloté par les tests oblige les développeurs à valider et à affiner leur code au fur et à mesure, ce qui rationalise les contrôles de qualité et les corrections finaux. 

Il existe d’autres cadres de test, qui consistent par exemple à écrire le code de production avant tous les tests automatisés ou à écrire l’ensemble des tests avant le code de production. Ces méthodes, bien que pas nécessairement inefficaces, ont montré qu’elles augmentaient le temps de débogage nécessaire, en particulier pour les projets plus importants et plus complexes.

Si le développement piloté par les tests est couramment utilisé pour la création de nouveau code de production, il est également souvent employé pour améliorer le débogage de code hérité développé avec des techniques plus anciennes ou différentes. 

Le développement piloté par les tests inverse le processus de développement traditionnel en plaçant les tests avant le développement. En tant qu’approche itérative, il améliore la qualité et la lisibilité du code en favorisant des workflows testables qui aboutissent à un code de haute qualité au niveau des unités. Lorsque les développeurs mettent en œuvre des tests unitaires, ils se concentrent sur une petite partie de la logique, telle qu’un algorithme individuel. L’écriture de code spécifiquement destiné à faire passer les tests permet non seulement d’obtenir un code plus propre et plus durable, mais contribue également à améliorer la documentation. 

Il existe deux niveaux principaux de développement piloté par les tests :

Pour le TDD d’acceptation (ATDD), parfois appelé développement piloté par le comportement (BDD), les programmeurs écrivent un seul test d’acceptation, puis suffisamment de nouveau code pour le faire passer. Ces tests sont parfois appelés tests clients ou tests d’acceptation par le client.

Ils peuvent généralement être considérés comme des cas de test requis pour vérifier les fonctionnalités minimales définies par les parties prenantes du produit. L’ATDD vise à d’identifier des exigences détaillées et exécutables. Les tests d’acceptation peuvent être effectués à l’aide de divers outils de test, tels que Fitnesse ou RSpec.

Parfois appelé simplement TDD, le TDD pour développeurs exige des codeurs qu’ils écrivent des tests uniques pour évaluer leur propre solution à un test ATDD. Le TDD pour développeurs utilise des outils d’automatisation des tests, tels que JUnit ou VBUnit. 

Lorsqu’ils emploient une stratégie de développement piloté par les tests, les codeurs écrivent d’abord des tests pour vérifier chaque élément ou fonction d’un logiciel avant d’écrire suffisamment de code pour passer ce test individuel. Une fois terminé, le logiciel est testé à nouveau ; s’il passe le test, le code est affiné (un processus appelé refactoring) pour n’inclure que les éléments essentiels. Les développeurs répètent ensuite ce processus pour chaque fonction logicielle suivante. 

Le processus de développement piloté par les tests se décompose en cinq étapes distinctes :

1. Avant d’écrire le code d’une fonction logicielle donnée, les développeurs écrivent d’abord un test unitaire individuel pour cette fonction.
2. Ils exécutent ensuite le test, qui devrait échouer car la fonction n’a pas encore été écrite. Cette étape est importante pour confirmer que le test lui-même est fonctionnel et ne renvoie pas de faux positifs. Si le code passe le test, le test doit être réécrit.
3. Lorsque le programme échoue, les développeurs écrivent uniquement le code logiciel supplémentaire nécessaire pour passer le test. 
4. Lorsque le code passe le test, le test et le code sont refactorisés pour plus de simplicité et pour éliminer tout code inutile. 
5. Lorsque le logiciel suffisamment refactorisé passe le test, les développeurs passent à la fonction logicielle suivante souhaitée. Les testeurs écrivent et exécutent ensuite des tests pour chaque nouvelle fonctionnalité. 

En termes simples, le processus de développement piloté par les tests suit une boucle répétitive, appelée cycle rouge-vert-refactoring. Les étapes du cycle sont les suivantes :

• Rouge : un test qui échoue est écrit pour le comportement logiciel souhaité. 

• Vert : suffisamment de code supplémentaire est écrit pour réussir le test.

• Refactoring : le code est affiné pour répondre autant que possible aux normes de simplicité tout en réussissant le test.

Bien que les origines spécifiques du développement piloté par les tests soient inconnues, le concept consistant à écrire d’abord les tests, puis le code de production, n’était pas une pratique courante avant le milieu des années 1990. Auparavant, les cadres de test empêchaient les développeurs de tester leurs propres bases de code. Mais avec l’évolution de l’ingénierie logicielle, les équipes DevOps ont exigé des méthodologies plus rapides et plus flexibles pour répondre aux demandes des parties prenantes, en particulier lorsque celles-ci changeaient rapidement. 

Le développement piloté par les tests a évolué à partir de divers cadres de test novateurs et parallèlement à ceux-ci, et a également été adopté comme composant modulaire dans divers autres cadres. Le TDD est notamment inclus dans le concept d’Extreme Programming (XP), un cadre de développement logiciel agile développé pour améliorer à la fois la qualité des logiciels et la qualité de vie des développeurs.

L’ingénieur logiciel Kent Beck, figure majeure de la communauté agile et créateur de l’Extreme Programming, est considéré comme ayant « redécouvert » le développement piloté par les tests. Selon ses propres mots : 

« La description initiale du TDD figurait dans un ancien livre sur la programmation. Elle disait qu’il fallait prendre la bande d’entrée, taper manuellement la bande de sortie attendue, puis programmer jusqu’à ce que la bande de sortie réelle corresponde à la sortie attendue. Après avoir écrit le premier cadre xUnit dans Smalltalk, je me suis souvenu avoir lu cela et j’ai essayé. C’est ainsi qu’est né le TDD pour moi. Lorsque je décris le TDD à des programmeurs plus âgés, j’entends souvent : "Bien sûr. Comment pourrait-on programmer autrement ?" C’est pourquoi je dis que j’ai "redécouvert" le TDD. » 

Voici quelques-unes des dates clés dans l’évolution du développement piloté par les tests :

• 1976 : Glenford Myers publie Software Reliability, dans lequel il affirme qu’« un développeur ne devrait jamais tester son propre code ». Bien que Myers ne soit peut-être pas à l’origine de ce concept, son travail a donné du crédit à une idée courante qui se répandrait au fil des années. 

• 1990 : au début de la décennie, la technique de la « boîte noire » était reine dans le domaine des tests logiciels. Dans ce type de cadre de test, les testeurs traitent le logiciel comme s’il s’agissait d’une « boîte noire », impénétrable et incompréhensible. Les tests de la boîte noire font appel à des testeurs qui, fondamentalement, n’ont aucune connaissance du fonctionnement interne du logiciel. 

• 1994 : Kent Beck développe SUnit, un cadre de test Smalltalk, jetant les bases d’une approche axée sur les tests pour l’optimisation du code. 

• 1999-2002 : alors que le mouvement du développement agile prend de l’ampleur, Kent Beck développe le concept d’Extreme Programming, codifiant le développement piloté par les tests et introduisant le concept essentiel des objets simulés. Le TDD emploie ces derniers pour simuler les comportements de dépendances réelles (par exemple, des bases de données, des services externes, etc.) pendant les tests. Cette méthode aide les développeurs à concentrer leur code de test sur des objets fictifs faciles à maintenir et dont le fonctionnement peut être évalué avec précision. Un test qui échoue en utilisant un objet simulé peut éliminer une dépendance potentiellement mal configurée comme source de l’échec. 

• 2003 : Kent Beck publie Test Driven Development: By Example, popularisant cette pratique auprès de la communauté des développeurs et légitimant davantage les tests pilotés par les développeurs. 

En tant que composante d’Extreme Programming, le développement piloté par les tests s’est avéré bénéfique non seulement pour créer un meilleur code, mais également pour améliorer les codeurs eux-mêmes. Le TDD leur permet de mieux comprendre leurs projets et contribue à la conception des programmes. En se concentrant sur le cas de test avant la mise en œuvre de chaque fonctionnalité, les développeurs doivent visualiser comment une fonction sera employée par un client ou un utilisateur. Cette approche place l’interface du produit avant la mise en œuvre et aide les développeurs à créer des applications plus centrées sur l’utilisateur. 

Voici d’autres avantages du développement piloté par les tests :

• Couverture complète des tests : le TDD est parfois considéré comme un outil de spécification ou de documentation, car cette pratique garantit que tout le code est évalué par au moins un test. 

• Documentation améliorée : pour la même raison que le TDD offre une couverture complète, il fournit également une documentation et des spécifications robustes. Ce système aide les développeurs, les chefs de projet et les autres parties prenantes à valider les fonctionnalités et les exigences du code et à établir un ordre tout au long du cycle de vie du projet. 

• Confiance accrue : les développeurs et les équipes DevOps qui utilisent le TDD gagnent en confiance non seulement dans leur code, mais aussi dans leurs tests. 

• Intégration continue simplifiée : le TDD est bien adapté aux pratiques d’intégration continue, dans lesquelles le code en production est continuellement mis à jour avec de nouvelles fonctionnalités et des correctifs. 

• Débogage réduit : le TDD anticipe les tests dans le processus de développement, ce qui réduit le besoin d’un débogage approfondi à la fin de ce processus. 

• Clarification des exigences : le TDD aide les développeurs à mieux comprendre chaque exigence spécifique du programme avant d’entamer leur travail. 

• Productivité améliorée : le TDD est souvent associé à une augmentation de la productivité des développeurs, car le processus permet de diviser les grands projets en étapes plus petites et plus faciles à réaliser. 

• Conception simplifiée : la troisième étape essentielle du cycle vert-rouge-refactoring exige des développeurs qu’ils refactorisent et simplifient leur code. Cette pratique améliore la simplicité et la qualité générales de la conception. 

• Modèles mentaux renforcés : en examinant et en intégrant chaque fonction ou exigence unique, le TDD aide les codeurs à développer un modèle mental robuste du code sur lequel ils travaillent. Ce modèle mental aide les développeurs à visualiser les fonctions et les exigences globales du code pendant qu’ils y travaillent. 

• Stabilité améliorée du système : il a été démontré que l’utilisation du développement piloté par les tests améliore la stabilité globale des applications en créant un code robuste et bien testé, conforme à des normes élevées en matière de simplicité de conception. 

Bien que l’utilisation du développement piloté par les tests (TDD) présente de nombreux avantages, elle n’est pas sans défis. Si la gravité de ces défis peut dépendre du projet ou être atténuée par diverses autres techniques, voici quelques-uns des inconvénients du TDD :

• Augmentation du volume de code : le TDD exige des codeurs qu’ils écrivent non seulement le code pour chaque fonctionnalité requise, mais aussi les tests pour chaque fonctionnalité. L’ajout du code de test au code du produit entraîne une augmentation de la base de code globale. 

• Confiance trompeuse : comme chaque fonctionnalité est écrite pour passer un test, les codeurs et les chefs de projet peuvent développer un faux sentiment de sécurité quant à la fonctionnalité globale du code. Même si chaque fonctionnalité intégrée est testée, le TDD ne remplace pas le contrôle qualité final et les tests API. 

• Frais généraux accrus : le TDD exige des codeurs qu’ils maintiennent également une suite complète de tests en plus de leur code de production. Cela exige une certaine quantité de ressources et peut augmenter les frais généraux. 

• Efficacité réduite : bien que le TDD ait démontré son efficacité pour améliorer la productivité, il peut retarder le développement d’un projet en ajoutant des étapes supplémentaires à la création et à la mise en œuvre de chaque nouvelle fonctionnalité. 

• Temps de configuration accru : le TDD exige des développeurs qu’ils configurent et maintiennent des environnements de test adaptés à leur code. 

• Conception globale négligée : bien que le TDD encourage la simplicité du code et l’amélioration de la conception, une trop grande attention portée aux composants individuels peut conduire à un code global moins fluide. Les codeurs qui emploient le TDD doivent savoir comment leurs mises à jour de fonctionnalités individuelles s’intégreront lorsqu’elles seront compilées dans l’application logicielle globale.