L'approche Test Driven Developpement

Le TDD est une approche Agile qui consiste à penser aux tests avant d'écrire du code.   

Les tests  sont un élément important dans le cadre du développement logiciel, nous pouvons distinguer les tests fonctionnels et les tests unitaires qui sont deux choses complémentaires.   

Le TDD concerne plutôt les tests unitaires et sont fait par les développeurs qui  implémentent les fonctionnalités demandées.  

Les premières réactions que j'ai lorsque je parle de TDD a un développeur moins familier à cette approche  se résume en quelques question ci-dessous  : 

• Comment écrire un test alors que le code n'existe pas ?  
• Qu'est-ce que je vais tester si je n’ai pas de code ?   
• Comment vais-je tester ?  
• Je perdre beaucoup de temps à écrire un test, je préfère coder directement  
• Les tests unitaires ne fonctionnent jamais (on a déjà essayé … il y'a des années en vain)  
• Un bon testeur n'a pas besoin d'écrire des tests   
• Etc.  

Certes, ces questionnements  sont justifiés, mais de la même manière on peut aussi poser les questions suivantes :  

• Comment écrire du code  alors qu'on ne connait pas les limites (tenant et aboutissant du code)  
• Comment garantir que le code qu'on écrit respecte les spécifications ?   
• Comment garantir qu'il fonctionne ou  qu'ils continuent de fonctionner et de répondre aux spécifications même après avoir été modifié?   
• Avons-nous pensé à tous les cas de figure ?   
• Comment garantir que le code fonctionne dans un environnement autre que notre poste de travail ?  
• Etc.  

L'approche TDD consiste :  
 

• Poser les bases de notre code et de définir les limites de son fonctionnement en respectant un cahier des charges, une user storie, 
• Décrire le comportement précis de nos fonctionnalités.  
• Préciser le comportement ultérieur de notre programmation en fonction des situations auxquelles il sera exposé.  
   

Le TTD  facilite la production d'un code valide en toutes circonstances,  plus juste et plus fiable et nus invite donc à voir notre programme comme une suite de fonctionnalités très précises, testables unitairement.  

Et même si on n’a pas une idée très précise de chaque fonctionnalité, nous pouvons définir le comportement de celle-ci avant d'implémenter  du code, cela évite souvent des erreurs de conception qui peuvent arriver lors qu'on écrit du code dans la précipitation.   

Avantage du TDD   

• Favorise  les modifications du code (refactoring)  
• Permet d'apporter des changements radicaux dans le code si besoin sans avoir peur des régressions 
• Permet d'avoir une suite de tests de non régressions qui peut être joués automatiquement avant la livraison du produit.  
• Permet l'échange entre développeur à travers la Méthode eXtreme Programming , qui encourage le Peer programming.   

Faire du TDD  consiste :  

1. Décrire un cas de  test simple     

• Donner un nom à la fonctionnalité qu'on souhaite tester   
• Décrire les prérequis, données d'entrées, données de sortie  
• Nom de  mon interface  qui correspond à mon service ou fonctionnalité.   
• etc.  

2. Définir et coder les  conditions qui font échouées notre programme. (Cas test unitaire/ scenario par scenario)  
3. Exécuter le code qui doit échouer en premier temps     
4. Implémenter  le code de la fonctionnalité. 
5. Re-exécuter les tests de nouveaux et voir s'il passe.  

Il faut répéter les étapes 1 à 5,  pour chaque cas de test identifié.    

 
Les TDD ont un cout éventuel en temps  mais cette charge travail permet  de créer un cercle vertueux et éviter des situations qui ne favorisent pas l'Agilité et le re-usinage de code (refactoring).