Avant de commencer un nouveau projet il est bon de se poser la question suivante :
« Comment je souhaite mettre en place les tests dans mon application ? »
Cette question doit obligatoirement se poser dès le début du projet pour pouvoir en bénéficier pleinement mais surtout pour ne pas perdre de temps, la mise en place des tests pendant le développement du projet pouvant être très chronophage pour les adapter au code déjà existant.
Pour normaliser la mise en place de ces tests, plusieurs méthodes ont été crées et sont maintenant devenues des standards. Parmi celles-ci, 3 méthodologies ressortent : TDD, BDD et ATDD.
Test Driven Development (TDD)
Le “test driven development”, ou en français, développement piloté par les tests est une technique de développement logiciel qui préconise les tests unitaires avant d’écrire le code source du projet.
Cette méthodologie propose de suivre les règles suivantes :
- Créer un seul test unitaire décrivant un aspect du programme
- S’assurer, en l’exécutant, que ce test échoue pour les bonnes raisons
- Ecrire juste assez de code, le plus simple possible, pour que ce test passe
- Remanier le code autant que nécessaire pour se conformer aux critères de simplicité
- Recommencer, en accumulant les tests au fur et à mesure
Cette pratique peut se schématiser de la façon suivante :
La mise en place de la méthode TDD offre de nombreux avantages au sein du développement d’un logiciel :
- Les tests unitaires sont réellement écrits
- En général, quand les tests unitaires sont écris à la fin d’un développement, ils sont souvent remis à plus tard (ou oubliés)
- Clarification des détails de l’interface et du comportement
- En se penchant sur les tests à implémenter en premier, cela oblige le développeur à réfléchir à la méthode qu’il mettra en place par la suite et à son implémentation.
- Vérification démontrable, répétable et automatisé
- Le fait de disposer d’un grand nombre de tests permet de s’assurer de la solidité et garantie du code.
- Non présence de régression
- La modification d’une méthode existante lancera automatiquement le test unitaire associé et permettra donc ainsi de s’assurer de la non régression de cette-ci.
- Un surcout modéré mais compensé
- La mise en place de ces tests implique un surcout modéré du développement initial. Mais celui-ci est en général rattrapé par la réduction significative du nombre de défauts.
Behavior Driven Development (BDD)
“Behavior driven development” ou BDD est une méthode agile qui encourage la collaboration entre les développeurs, responsables qualités et intervenants non-techniques participant à un projet logiciel.
Cette technique va permettre de lier, dans un projet de développement, des demandes de l’équipe fonctionnelle.
Cette méthodologie a été conçue pour palier à la problématique suivante :
«
Un projet de développement passe d’abord par une phase de spécifications rédigées pendant des semaines/mois/années par des experts du métier et/ou consultants fonctionnels.
Ces spécifications sont ensuite transmises à l’équipe de développement.
Cette interaction passe en grande partie par une transmission de documents, une lecture du développeur et donc nécessairement une partie d’interprétation.
Cette interprétation conduit souvent à un développement inadapté à la demande, voir inutile.
»
Pour solutionner cette problématique, la méthode BDD préconise de réunir dans un même document des exigences (User Stories) exprimées selon le formalisme « rôle-fonction-bénéfice », et des scénarios ou exemples exprimés selon le canevas « given-when-then ».
La rédaction de ce document va permettre à l’expert métier, au consultant fonctionnel et au développeur de se comprendre, via un langage naturel :
- On utilise des phrases, dans la langue du projet.
- On parle de besoin et non de solution, dans un langage non technique.
- On utilise des termes provenant du langage omniprésent partagé par tous
La finalité du point de vue logiciel est multiple :
- Le code créé est à l’image de la demande de l’utilisateur.
- La fonctionnalité est à l’image de la demande de l’utilisateur (On ne code que la fonctionnalité et rien de plus).
- L’implication et la réflexion des experts métier avec les développeurs permet de débloquer un grand nombre de problème non couvert et assurent une grande qualité de production.
BDD est, dans ce sens, fortement lié au fonctionnement de TDD ou l’on ne code que le minimum pour que le code de production fonctionne (Le refactoring permet d’être clair et d’obtenir le meilleur design, il n’y a pas de redondance, …). Le BDD est la couche “fonctionnelle”, allant de pair avec le TDD.
Pour plus d’informations sur la méthode BDD : http://coding-in.net/tout-savoir-ou-presque-sur-le-behaviour-driven-development-bdd-2/
Acceptance Test-Driven Development (ATDD)
L’ATDD correspond à la contraction de “Acceptance Test Driven Development”, ou en français, Pilotage par les tests métiers.
Cette méthode est une approche de développement logiciel itérative et incrémentale basée sur un principe fondamental : les tests sont au cœur du projet.
Cette méthodologie propose de suivre les règles suivantes :
- Les tests servent aux spécifications générales du logiciel
- Les tests sont donc créés et automatisés en amont du développement
- Le développement est ensuite réalisé en fonction des tests
- Les tests sont exécutés automatiquement et permettent de définir lorsque le code est terminé (lorsque tous les tests sont au vert).
C’est un procédé itératif pour impulser de la réactivité et du dynamisme aux équipes (comme initié dans l’Agile) et incrémental car il y a une capitalisation sur les tests créés dans les itérations (les tests automatisés de l’itération 1 serviront aux tests de non régression des itérations suivantes).
Cette pratique peut se schématiser de la façon suivante :
Plus d’informations sur la méthodologie ATDD dans un projet JavaScript : http://www.codeproject.com/Articles/659570/Acceptance-Test-Driven-Development-for-JavaScript