Les erreurs de code ont un coût pour le commanditaire d’un logiciel. Lorsqu’elles surviennent en phase de production, elles ralentissent son activité. Durant le processus de recette, un nombre élevé de bogues dans une version retardera sa livraison. Il est donc important de minimiser les risques de survenue de ces comportements inattendus et des régressions de fonctionnalités dès la phase de développement.

Test Driven Design

Le Test Driven Design (TDD) place l’écriture des tests unitaires au rang de bonne pratique fondamentale dans la lutte contre ces risques. Le TDD préconise de commencer par l’écriture de tests, puis de procéder par itérations successives, alternant le lancement des tests avec l’implémentation ou la refonte du code livrable. La règle à suivre lors de la phase d’implémentation est de ne toujours implémenter que le minimum faisant passer le test. Une phase de remaniement (refactoring) peut s’avérer nécessaire une fois que l’ensemble des tests passe au vert pour maximiser sa qualité.

Les bénéfices

De cette manière, l’accent est mis sur le contrat que doit remplir la méthode testée. La réussite de tous les tests garantit que le contrat est rempli. Le développeur peut en disposer comme d’un outil de vérification pour faire évoluer le code sans risque de régression.
La qualité du code est également améliorée. D’une part, le code orienté par les tests se révèle souvent plus lisible car il tend à ne comporter que le minimum nécessaire.
D’autre part, les tests définissent une documentation précieuse d’une méthode en terme d’entrée et de sortie et de comportements attendus. C’est un atout intéressant dans le contexte de projet agile, aux mises à jour de code fréquentes, et de projet avec un renouvellement fréquent de l’équipe, face au besoin de montée en compétence rapide.
Cependant, le TDD ne résout pas tous les problèmes, en partie, car les tests sont orientés techniques.

Les limites

Dans la plupart des projets, le besoin du métier est recueilli par les profils fonctionnels. Or, avec l’approche TDD, le développeur est le seul profil de l’équipe qui écrit et déroule les tests. La réussite de ceux-ci dépendra de leur qualité, et en particulier, d’une bonne compréhension du besoin du métier, traduit dans la bonne granularité et avec une bonne couverture de tests.
Malgré la préconisation d’une implémentation minimale à chaque itération, il existe encore un risque que le développeur parvienne à faire passer les tests dans le non-respect des bonnes pratiques de programmation (nommages, découpage du code…) qui rendrait le code moins évolutif. Néanmoins, la présence des tests permettra de ré-usiner le code sans risque par la suite.
Enfin,en s’appuyant uniquement sur les tests unitaires, par définition indépendants et reproductibles unitairement, la vérification de la bonne marche d’un comportement du logiciel qui serait la succession de comportements interdépendants dans un contexte précis n’est pas envisagée.
L’approche BDD a été pensée pour répondre à la majorité de ces limites.

Behaviour Driven Design

Le Behaviour Driven Design (BDD) étend le potentiel du TDD en proposant la définition de tests orientés comportement, écrits par un profil fonctionnel dans un langage naturel. Les cas de tests sont structurés selon le modèle GIVEN-WHEN-THEN (nommé Gherkin). Comme le montre l’exemple ci-après, GIVEN décrit le contexte, WHEN l’action de l’utilisateur et THEN les comportements attendus.

SCENARIO paiement avec un code promotionnel
GIVEN  le client  « Mme D. » est authentifié
AND son panier comporte les produits suivants
     produit  | prix | quantité
     robe     |  65  |        1
AND le client a une adresse de livraison
AND le client a choisi un mode de paiement
AND le client indique le code promotionnel «MOINS10%»
WHEN le client  demande le paiement de sa commande
THEN le panier est vide
AND la facture donnée indique
    nom    | produit | prix total
    Mme D. |  1 robe |       58,5

La tenue d’un tri-amigos, une réunion confrontant les visions des profils fonctionnels et des profils techniques de l’équipe, favorise l’explicitation de tous les scénarios significatifs, y compris les traitement des erreurs, et la dissipation des imprécisions
Le fichier feature produit sert de trame pour le développeur. Chaque phrase est traduite sous forme d’une méthode, réalisant soit l’initialisation des conditions (GIVEN), soit les opérations (WHEN), soit les assertions de comportements (THEN) définis par le scénario. Le test est déroulé dans l’ordre des phrases par appels successifs de l’ensemble de ces méthodes interdépendantes.

Les bénéfices

La description des attentes est disponible pour tous dans un format compréhensible par tous. En favorisant la discussion entre fonctionnels et techniques, cette approche peut mener à l’émergence d’un langage commun aussi bien dans les définitions de tests que dans le code. Ce sera un atout pour la communication au sein de l’équipe.
Enfin, la mise en place du BDD contraint le développement à la validation de scénarios (tests d’intégration) là où le TDD ne contraint qu’à la validation de règles métier sans liaison entre elles (tests unitaires).

Les limites

La mise en place initiale de cette approche peut être longue avant que l’équipe ne soit suffisamment experte, mais sur le long terme, la présence des BDD deviendra un gain de temps en diminuant le nombre d’incidents.

Conclusion

Ces approches apportent au produit une meilleure stabilité et une meilleure documentation, et à l’équipe une vision partagée des problématiques métier. Afin de s’assurer de profiter de leurs bénéfices, les tests BDD et TDD doivent être lancés régulièrement avant chaque livraison et de préférence dès la livraison sur un environnement d’intégration. Il est fortement recommandé d’automatiser leur lancement.
Néanmoins, elles ne sont pas suffisamment contraignantes pour lutter contre d’autres facteurs d’apparition de bogues comme un mauvais design. De bonnes pratiques de développement doivent être mises en place comme par exemple le pair programming (code en binôme) ou la revue de code.