Les méthodologies TDD, BDD, ATDD …

Avec l’accroissement de la taille des projets et leur criticité, il est devenu évident de mettre en place des pratiques de software craftmanship. Il s’agit notamment de rendre un code multiplateforme, faire en sorte d’éviter les régressions lors de nouvelles fonctionnalités et évidemment, que les développements correspondent en tout point à la demande du client dans un temps acceptable.
Des méthodologies visant à améliorer et stabiliser le code des développeurs ainsi que la finalité des projets sont nées.
Commençons par la méthodologie la plus populaire, à savoir le TDD qui signifie Test-Driven Developpement (ou Développement dirigé par les tests en français).

TDD
Le TDD est l’une des multiples techniques permettant de rendre son code plus sûr et plus facilement maintenable. Il repose sur le refactoring basé sur des tests unitaires.

Concept
Le TDD impose l’écriture de tests avant la mise en place du code en tant que tel. Cette technique est de plus en plus utilisée par les développeurs, soucieux de rendre un code fiable et facilement évolutif.
Idéalement, il faudrait que le rédacteur des tests unitaires et le développeur de l’application soient deux personnes différentes, mais c’est en réalité, souvent très compliqué à appliquer.

Concrètement, le TDD est composé de cinq étapes :

1. On écrit en premier lieu, le test ;
2. On exécute le test en s’assurant bien qu’il échoue (il n’y a encore aucun code à tester réellement) ;
3. On implémente de la manière la plus simple possible le code qui permettra de valider le test ;
4. On exécute de nouveau le test qui doit cette fois ne pas échouer. Le code respecte alors les règles fonctionnelles des tests unitaires ;
5. On refactorise notre code.

On itère sur les étapes 1 à 4 jusqu’à ce qu’il ne soit plus possible d’améliorer le code. On peut généralement admettre qu’il n’y a plus de refactoring possible lorsque cette étape dépasse les 10 minutes. En effet, il est préférable d’effectuer des cycles rapides proposant de faibles améliorations. On préfèrera effectuer plus de cycles qui valideront les tests plutôt que peu de cycles comportant de grosses améliorations.
Vulgairement, on peut également réduire ces étapes en trois phases :
Red – Green – Refactor.
Red et Green correspondent aux couleurs de réussite ou d’échec des tests unitaires.

• Red : le test échoue
• Green : le test est validé
• Refactoring

Demo :
Réalisation de l’algorithme du FizzBuzz en TDD en C#
Pour rappel, l’algorithme FizzBuzz consiste en une suite continue de nombre allant de 1 à 100. Pour chaque multiple de 3, on affiche Fizz, pour un multiple de 5, on affiche Buzz et pour un multiple de 15, on affiche FizzBuzz.
On doit donc notamment obtenir une suite comme suit :
1 2 Fizz 4 Buzz Fizz 7 8 Fizz … etc.
On se base dans notre exemple sur un maximum de 15 valeurs
On commence notamment par créer un test unitaire qui vérifie la chaîne en sortie.

Lorsque l’on exécute en premier lieu, cela ne fonctionnera pas, car nous n’avons pas encore implémenté notre fonction FizzBuzz. (Red)
On crée donc notre classe FizzBuzz et l’algorithme FizzBuzz.

A l’exécution, notre test unitaire pourra bien fonctionner. (Green) Il faut donc maintenant refactoriser notre code. (Refactor)
On obtient notre Red – Green – Refactor
Après plusieurs itérations de refactoring, on peut en arriver à un résultat de ce type, qui est certainement encore refactorisable.

Tout d’abord notre classe de test :

Et la classe correspondante :

Et enfin le programme d’exécution :

ATDD
L’ATDD pour Acceptance Test-Driven Developpment (Développement dirigé par les tests d’acceptation) étend la méthode de TDD originelle. En plus d’écrire des tests unitaires, on réalise des tests d’acceptation.
Le TDD est une pratique destinée et utilisée par le développeur, alors que l’ATDD est une pratique pour l’ensemble de l’équipe.

Concept
Pour chaque test d’acceptation, le développeur rédige les tests unitaires associés. L’ensemble des tests sont au préalable en échec.
En Agile, une user story doit être réalisée à chaque itération, mais la difficulté est de savoir si celle-ci est belle est bien terminée à la fin de cette itération. Il faut pour cela que cette story accepte l’ensemble des conditions.
L’ATDD implique que le développement ne commence que lorsque les tests d’acceptation sont à disposition.
On a donc le principe suivant :

1. On réalise les story tests de la story en cours.
2. On réalise le développement selon la méthode du TDD
3. On passe enfin les story tests et on corrige les tests/code en cas d’échec.

BDD
Le BDD ou Behaviour Driven Developpement (Développement dirigé par le comportement) est encore une autre méthodologie, étroitement liée à l’ATDD. La démarche se base plutôt ici sur les tests à partir de la spécification. Le client est ici beaucoup plus intégré dans le développement.
Concept
Concrètement, des scénarios de tests sont établis. On se base sur un état initial et on cherche à vérifier le comportement après passage d’un traitement.
Les scénarios BDD se déroulent sous le format suivant : Given (Etat de départ) / When (condition) / Then (Alors). On appelle également cela le langage de Gherkin.

Exemple :
On pourra prendre pour exemple un système de paiement sur un site e-Commerce. Nous pourrions donc avoir différentes user stories du type :

1. Mon panier ne possède pas d’article
2. Je clique sur mon panier
3. Je ne peux pas avoir accès au bouton de paiement

Ou encore

1. Mon panier possède des articles
2. J’ajoute un bon d’achat
3. Le prix de mon panier doit diminuer

L’intérêt est notamment que le développeur puisse comprendre la logique générale sans entrer dans les détails techniques. Cela facilite la communication entre les développeurs et les autres intervenants.
 
Vocabulaire
Software Craftmanship :
C’est une méthodologie de développement qui se base sur les bonnes pratiques de développement telles que les principes SOLID, l’utilisation de design Patterns ou encore le développement TDD.
Il s’agit d’une philosophie de développement, où il est important de partager ses connaissances et de produire un travail propre, qui n’a pas pour seul but de retourner un résultat mais surtout un standard propre et aisément maintenable.

User Story :
Une User Story est une incrémentation dans des méthodes Agile, qui correspond à une demande client. On parle alors parfois de scénario client. Elle doit être claire et compréhensible par les différents acteurs du projet.