Écrit par Abdourahmane Sow
Avant de commencer à entrer dans le vif du sujet, je vais vous donner quelques raisons pour lesquelles il est important d’écrire des tests.
- Rédiger un meilleur code.
- Débogage plus facile.
- Minimiser les régressions.
- Refactoriser en toute confiance.
- Gagner plus de temps.
Le TDD c’est quoi ?
Le développement piloté par les tests (TDD) est une approche du développement logiciel dans laquelle vous écrivez d’abord des tests, puis utilisez ces tests pour piloter la conception et le développement de votre application logicielle.
Ce cycle est aussi connu sous le nom de Rouge Vert et Refactor
Cycle Rouge-Vert-Refactor
L’approche du rouge, vert et refactorisation aide les développeurs à compartimenter leur attention en trois phases :
Rouge : Pensez à ce que vous voulez développer.
Vert : Réfléchissez à la façon de réussir vos tests.
Refactoriser : Réfléchir à la façon d’améliorer votre implémentation existante.
Processus de TDD
Il y a 5 étapes dans le flux TDD :
- Lisez, comprenez et traitez la demande de fonctionnalité.
- Traduisez l’exigence en écrivant un test unitaire. Si vous le lancez, le test unitaire s’exécutera et échouera car aucun code n’est encore implémenté.
- Rédigez et implémentez le code qui répond à l’exigence. Exécutez tous les tests et ils devraient réussir, sinon répétez cette étape.
- Nettoyez votre code en le refactorisant.
- Rincez, faire mousser et répéter.
Les frameworks pour faire du TDD
Il existe beaucoup de framework pour faire du TDD. Je vais vous en citer quelques une :
JUnit : un framework de test de pour le langage JAVA.
PhpUnit : un framework de test pour Php
Selenium : un framework de test pour Python
Testing : un framework de test pour JAVA
Karma : un framework de test pour Javascript
BDD (Behavior Driven Development)
Le BDD est une approche de test dérivée de la méthodologie Test-Driven Development (TDD). Dans BDD, les tests décrivent le comportement du système. Dans la plupart des cas, l’ approche Given-When-Then est utilisée pour écrire des cas de test.
Pourquoi faire du BDD :
Le BDD a de nombreux avantages :
- Encourager la collaboration entre les rôles pour construire une compréhension partagée du problème à résoudre.
- Augmenter la rétroaction et le flux de valeur.
- Produire une documentation système qui est automatiquement vérifiée par rapport au comportement du système.
Pour ce faire, il faut concentrer le travail collaboratif sur des exemples concrets et réels qui illustrent la façon dont nous voulons que le système se comporte. Nous utilisons ces exemples pour nous guider du concept à la mise en œuvre, dans un processus de collaboration continue.
BDD et agile
Le BDD ne remplace pas votre processus agile existant, il l’améliore.
Le BDD est comme un ensemble de plug-ins pour le processus existant. Il rendra l’équipe plus à même de tenir les promesses de l’agilité : des versions rapides et fiables de logiciels fonctionnels qui répondent aux besoins évolutifs de l’organisation, nécessitant des efforts de maintenance et de la discipline.
BDD en trois (3) pratiques
Essentiellement, le BDD est un processus itératif en trois étapes :
- Tout d’abord, prenez un petit changement à venir dans le système une User Story et parlez d’exemples concrets de la nouvelle fonctionnalité pour explorer, découvrir et convenir des détails de ce qui doit être fait.
- Ensuite, documentez ces exemples d’une manière qui peut être automatisée et vérifiez leur accord.
- Enfin, implémentez le comportement décrit par chaque exemple documenté, en commençant par un test automatisé pour guider le développement du code.
L’idée est de rendre chaque changement petit et d’itérer rapidement, en remontant d’un niveau chaque fois que vous avez besoin de plus d’informations. Chaque fois que vous automatisez et implémentez un nouvel exemple, vous ajoutez quelque chose de précieux à votre système et vous êtes prêt à répondre aux commentaires.
Nous appelons ces pratiques Découverte, Formulation et Automatisation.
Définissez les choses à tester
Exemple : Imaginons que l’on souhaite ajouter une fonctionnalité de commentaire pour l’application interne de Ouidou StarOuids pour permettre aux collaborateurs de Ouidou de laisser des avis.
Les fonctionnalités que nous pourrions tester :
- la taille limite.
- un commentaire vide.
- si tout le monde a le droit de commenter.
- etc.
La syntaxe BDD
Les syntaxes seront souvent en anglais :Étant donné : Given Quand : When Alors : Then Et : And
Exemple :
Vos scénarios doivent décrire le comportement prévu du système, pas la mise en œuvre. En d’autres termes, il doit décrire le quoi, pas comment.
Par exemple, pour un scénario d’authentification, vous devez écrire :
Étant donné que je visite "/login"
Quand j'entre "Abdou" dans le champ "nom d'utilisateur"
Et j'entre "testeur" dans le champ "mot de passe"
Et j'appuie sur le bouton "connexion"
Alors, je devrais voir la page "Accueil"
Envisagez un style plus déclaratif :
Une façon de rendre les scénarios plus faciles à maintenir est d’utiliser un style déclaratif. Le style déclaratif décrit le comportement de l’application, plutôt que les détails de l’implémentation. Les scénarios déclaratifs se lisent mieux. Un style déclaratif vous aide à vous concentrer sur la valeur que le client veut obtenir, plutôt que sur les frappes qu’il utilisera.
Les tests impératifs communiquent des détails et, dans certains contextes, ce style de test est approprié. D’autre part, parce qu’ils sont si étroitement liés à la mécanique de l’interface utilisateur actuelle, leur maintenance nécessite souvent plus de travail. Chaque fois que la mise en œuvre change, les tests doivent également être mis à jour.
Voici un exemple de fonctionnalité dans un style impératif :
Fonctionnalité : Gestion des droits dans l'application starOuids Scénario : Les collaborateurs n'ayant pas les droits Étant donné qu'un utilisateur a un compte ouidou Et qu'il se connecte avec ses identifiants valides Et qu'il n'a pas un rôle admin Alors il doit juste pouvoir consulter. Scénario : Les collaborateurs ayant les droits admins Étant donné qu'un utilisateur a un compte ouidou Et qu'il se connecte avec ses identifiants valides Et qu'il a un rôle admin Alors il doit pouvoir créer, consulter , modifier , supprimer
Faire du BDD et du TDD avec JIRA :
Il est possible de faire du BDD avec JIRA grâce aux plugins Xray ou AssertThat.
- Écrire des scénarios BDD dans Jira pour une collaboration facile :
Avec AssertThat au cœur du processus BDD, vous pouvez écrire les comportements pour une compréhension commune des users stories.
2. Intégration avec les frameworks d’automatisation des tests :
Accélérez l’automatisation des tests pour un retour rapide, avec les plugins, les API client et les intégrations (Jenkins, Gradle, Maven, Karate Framework et bien d’autres).
3. Suivre et analyser les résultats de l’automatisation des tests dans Jira
Pas besoin d’outils de reporting séparés, vos résultats de test sont réimportés dans Jira. Analysez facilement les tests ayant échoué, reliez les défauts et identifiez les tendances dans les résultats des tests automatisés pour une gestion des tests très efficace.
Différence entre TDD et BDD
J’ai essayé de résumer dans un tableau 5 différences clé en TDD et BDD
Conclusion
TDD et BDD sont deux méthodes qui peuvent parfaitement se combiner ensemble. Avec BDD, vous avez la possibilité de décrire le comportement de l’application et le TDD permettra de les transformer en des tests unitaires.
Pour aller plus loin
L’importance d’écrire les tests en amont :
Myth: “code must be tested by someone else”
… and thus, by dedicated testers
Les différents outils de rédactions de spécifications exécutables :
Comparatif outils de rédaction de spécifications exécutables
Pour les démarches type ATDD, BDD, SpecByExample
Source :
TDD vs BDD vs ATDD : Key Differences | BrowserStack
This guidepost aims to describe different testing methods or practices like Behavioral Driven Development (BDD)…
BDD vs TDD – My Agile Partner Scrum
Quelle est la différence entre le TDD et la BDD (BDD vs TDD) ? Vous êtes nombreux à me poser cette question donc je…
À lire aussi
Fresque du Numérique
Ouicommit – L’intelligence artificielle en entreprise, on y est !
Hackathon Women in Tech : un engagement pour une tech plus inclusive
