Pendant très longtemps, la règle des projets informatiques étaient de dissocier les équipes de Dev et les équipes de Tests. La notion de TDD est apparue avec la codification de Kent Beck dans les années 2000 et donnera naissance à diverses méthodologies mais qui tournent autour de principes communs et totalement intégrés aux méthodes agiles.
Pour aider la communauté de développeurs du Tarmac, l’équipe de vrtice a mis en place des coding dojos bimensuels pour partager… par la pratique, les bonnes pratiques de développement dans une logique d’agilité et d’intégration continue.
Les grands principes du TDD
Le TDD est une technique de développement mêlant intimement l’écriture des tests unitaires, la programmation et l’amélioration continue du code (encore appelée refactorisation). Pour être unitaire, un test ne doit pas communiquer avec une base de données ni avec d’autres ressources ou systèmes d’informations sur le réseau, il ne manipule aucun fichier, il peut s’exécuter en même temps que les autres tests unitaires et il ne doit pas être lié à une autre fonctionnalité ou à un fichier de configuration pour être exécuté.
Chaque fonction unitaire de l’application possède son propre test unitaire, écrit avant le code. Le test est écrit dans un premier temps pour échouer. Le développeur s’assure ainsi en écrivant le test des conditions de réussite, mais aussi d’échec, de la fonction. Puis le développeur écrit la fonction demandée, de façon à ce que le test réussisse. Le code source produit pour réaliser la fonction demandée doit alors être le plus simple et le plus réduit possible, de façon à juste réaliser ce qui est demandé, pour que le test réussisse. Une fois le code source écrit et fonctionnel, une dernière étape de refactorisation permet de vérifier qu’il répond bien aux critères de simplicité demandés.
(source : https://www.nutcache.com/fr/blog/tdd-test-driven-development/ )
Concrètement, le TDD se décompose en 5 étapes distinctes :
- Écrire un test,
- Vérifier qu’il échoue (puisqu’il n’y a pas de code correspondant),
- Écrire le code suffisant pour que le test passe,
- Vérifier que le test passe,
- Optimiser le code et vérifier qu’il n’y ait pas de régression.
Les avantages du TDD
Les tests tels qu’ils sont mis à profit dans TDD permettent d’explorer et de préciser le besoin, puis de spécifier le comportement souhaité du logiciel en fonction de son utilisation, avant chaque étape de codage. Le logiciel ainsi produit est tout à la fois pensé pour répondre avec justesse au besoin et conçu pour le faire avec une complexité minimale. On obtient donc un logiciel mieux conçu, mieux testé et plus fiable, autrement dit de meilleure qualité.
Le fait d’écrire les tests avant le code en TDD est donc à l’origine d’implémentations testables, c’est-à-dire facilement testables et testables à 100%. Or la testabilité du code favorise une meilleure conception par un couplage lâche et une cohésion forte, ce qui évite des erreurs communes de conception.
Le TDD permet notamment :
- d’éviter des modifications de code sans lien avec le but recherché, car on se focalise étape par étape sur la satisfaction d’un besoin, en conservant le cap du problème d’ensemble à résoudre.
- d’éviter les accidents de parcours, où des tests échouent sans qu’on puisse identifier le changement qui en est à l’origine, ce qui aurait pour effet d’allonger la durée d’un cycle de développement.
- de maîtriser le coût des évolutions logicielles au fil du temps, grâce à une conception du code perméable au changement.
- de s’approprier plus facilement n’importe quelle partie du code en vue de le faire évoluer, car chaque test ajouté dans la construction du logiciel explique et documente le comportement du logiciel en restituant l’intention des auteurs.
- de livrer une nouvelle version d’un logiciel avec un haut niveau de confiance dans la qualité des livrables, confiance justifiée par la couverture et la pertinence des tests à sa construction
TDD / BDD : une approche par les tests … et l’usage
Le BDD (Behavior Driven Development) est présenté comme une évolution du TDD (Test Driven Development). Proposé par Dan North (qui fut aussi l’un des initiateurs du projet JBehave), le BDD consiste à étendre le TDD en écrivant non plus du code compréhensible uniquement par des développeurs, mais sous forme de scénario compréhensible par toutes les personnes impliquées dans le projet.
Cette technique est une réponse au développement piloté par les tests. Son objectif est d’harmoniser les conversations entre tous les interlocuteurs responsables de la définition du produit ou du service.
Un test en BDD consiste à décrire une fonctionnalité selon un formalisme « Given / When / Then » :
- Given :
La description, il permet généralement de décrire l’état initial - When :
L’action, il s’agit des actions effectuées (appel d’une méthode,…) - Then :
La vérification, elle est présente pour vérifier que le résultat attendu (par exemple que le message affiché contient bien tel message
Pour en savoir plus et pratiquer : rejoignez les vrtice Tech Lunch !
À propos des vrtice TechLunch
L’objectif de ces Meetup, dédiés à la communauté de développeurs du Tarmac et de la région grenobloise, est de favoriser le partage de connaissances technologiques, axées principalement logiciel mais pas seulement. Son ambition est d’organiser des sessions régulières sur inovallée dans le but de faire progresser les participants.
Ce groupe est animé par la startup vrtice, mais il s’adresse à tous ceux qui veulent venir partager un bout de tech le temps d’une pause déjeuner. Aucune cotisation, ou frais de participation ne sont requis pour ces évènements.
