BDD - Développement piloté par les tests
Lorsque vous regardez une référence sur le développement piloté par le comportement, vous trouverez l'utilisation d'expressions telles que «BDD est dérivé de TDD», «BDD et TDD». Pour savoir comment le BDD est né, pourquoi on dit qu'il est dérivé du TDD et ce que sont BDD et TDD, vous devez avoir une compréhension du TDD.
Pourquoi tester?
Pour commencer, passons aux principes fondamentaux des tests. Le but des tests est de s'assurer que le système construit fonctionne comme prévu. Prenons l'exemple suivant.
Par conséquent, par expérience, nous avons appris que la découverte d'un défaut au fur et à mesure de son introduction et sa réparation immédiate serait rentable. Par conséquent, il est nécessaire d'écrire des cas de test à chaque étape du développement et des tests. C'est ce que nos pratiques de test traditionnelles nous ont appris, ce que l'on appelle souvent Test-early.
Cette approche de test est appelée approche Test-Last car le test est effectué après l'achèvement d'une étape.
Défis avec l'approche Test-Last
L'approche Test-Last a été suivie pendant un certain temps dans les projets de développement logiciel. Cependant, en réalité, avec cette approche, comme les tests doivent attendre la fin de l'étape particulière, ils sont souvent négligés à cause de -
Les retards dans l'achèvement de l'étape.
Calendriers serrés.
Concentrez-vous sur la livraison à temps, en sautant les tests.
De plus, dans l'approche Test-Last, les tests unitaires, qui sont censés être effectués par les développeurs, sont souvent ignorés. Les différentes raisons trouvées sont basées sur l'état d'esprit des développeurs -
Ce sont des développeurs et non des testeurs.
Les tests sont sous la responsabilité des testeurs.
Ils sont efficaces dans le codage et leur code n'aurait pas de défauts.
Cela se traduit par -
Compromettre la qualité du produit livré.
Avoir la responsabilité de la qualité sur les testeurs uniquement.
Coûts élevés de réparation des défauts, après livraison.
Incapacité à obtenir la satisfaction du client, ce qui signifierait également une perte de clientèle répétée, affectant ainsi la crédibilité.
Ces facteurs ont appelé à un changement de paradigme, à se concentrer sur les tests. Le résultat a été l'approche Test-First.
Approche du premier test
L'approche Test-First remplace la méthode de développement de l'intérieur vers l'extérieur (écrire du code, puis tester) vers l'extérieur vers l'intérieur (écrire un test puis coder).
Cette approche est intégrée aux méthodologies de développement logiciel suivantes (qui sont également Agiles) -
eXtreme Pprogrammation (XP).
Test Ddéchiré Ddéveloppement (TDD).
Dans ces méthodologies, le développeur conçoit et écrit les tests unitaires pour un module de code avant d'écrire une seule ligne du module de code. Le développeur crée ensuite le module de code dans le but de réussir le test unitaire. Ainsi, ces méthodologies utilisent les tests unitaires pour piloter le développement.
Le point fondamental à noter que l'objectif est le développement basé sur des tests.
Cycle Red-Green-Refactor
Le développement piloté par les tests est utilisé pour développer le code guidé par des tests unitaires.
Step 1 - Considérez un module de code qui doit être écrit.
Step 2 - Ecrire un test
Step 3 - Exécutez le test.
Le test échoue, car le code n'est toujours pas écrit. Par conséquent, l'étape 2 est généralement appelée écrire un test pour échouer.
Step 4 - Ecrire le code minimum possible pour réussir le test.
Step 5- Exécutez tous les tests pour vous assurer qu'ils réussissent tous. Les tests unitaires sont automatisés pour faciliter cette étape.
Step 6 - Refactor.
Step 7 - Répétez les étapes 1 à 6 pour le module de code suivant.
Chaque cycle doit être très court et une heure typique doit contenir plusieurs cycles.
Ceci est également connu sous le nom de Red-Green-Refactor cycle, où -
Red - Ecrire un test qui échoue.
Green - Ecrire du code pour réussir le test.
Refactor - Supprimer la duplication et améliorer le code aux normes acceptables.
Étapes du processus TDD
Les étapes d'un processus TDD sont illustrées ci-dessous.
Avantages du TDD
Les avantages ou avantages du développement piloté par les tests sont:
Le développeur doit d'abord comprendre quel devrait être le résultat souhaité et comment le tester avant de créer le code.
Le code d'un composant n'est terminé que lorsque le test réussit et que le code est refactoré. Cela garantit les tests et la refactorisation avant que le développeur ne passe au test suivant.
Comme la suite de tests unitaires est exécutée après chaque refactorisation, le retour d'information indiquant que chaque composant fonctionne toujours est constant.
Les tests unitaires agissent comme une documentation vivante toujours à la hauteur des données.
Si un défaut est trouvé, le développeur crée un test pour révéler ce défaut, puis modifie le code pour que le test réussisse et que le défaut soit corrigé. Cela réduit le temps de débogage. Tous les autres tests sont également exécutés et lorsqu'ils réussissent, cela garantit que la fonctionnalité existante n'est pas interrompue
Le développeur peut prendre des décisions de conception et refactoriser à tout moment et l'exécution des tests garantit que le système fonctionne toujours. Cela rend le logiciel maintenable.
Le développeur a la confiance nécessaire pour apporter tout changement car si le changement affecte une fonctionnalité existante, la même chose est révélée en exécutant les tests et les défauts peuvent être corrigés immédiatement.
À chaque essai successif, toutes les corrections de défauts précédentes sont également vérifiées et la répétition du même défaut est réduite.
Comme la plupart des tests sont effectués pendant le développement lui-même, les tests avant livraison sont raccourcis.
Inconvénients du TDD
Le point de départ est les User Stories, décrivant le comportement du système. Par conséquent, les développeurs sont souvent confrontés aux questions suivantes -
Quand tester?
Que tester?
Comment savoir si une spécification est respectée?
Le code offre-t-il une valeur commerciale?
Idées fausses sur TDD
Les idées fausses suivantes existent dans l'industrie et nécessitent des clarifications.
| Idée fausse | Clarification |
|---|---|
| TDD concerne les tests et l'automatisation des tests. | TDD est une méthodologie de développement utilisant l'approche Test-First. |
| TDD n'implique aucune conception. | TDD comprend une analyse critique et une conception basée sur les exigences. Le design émerge au cours du développement. |
| Le TDD est uniquement au niveau de l'unité. | TDD peut être utilisé au niveau de l'intégration et du système. |
| TDD ne peut pas être utilisé par les projets de test traditionnels. | TDD est devenu populaire avec Extreme Programming et est utilisé dans d'autres méthodologies Agile. Cependant, il peut également être utilisé dans les projets de test traditionnels. |
| TDD est un outil. | TDD est une méthodologie de développement, et après chaque nouveau test unitaire réussi, il est ajouté à la suite de tests d'automatisation car tous les tests doivent être exécutés chaque fois qu'un nouveau code est ajouté ou qu'un code existant est modifié et également après chaque refactoring. Ainsi, les outils d'automatisation des tests prenant en charge TDD facilitent ce processus. |
| TDD signifie remettre les tests d'acceptation aux développeurs. | TDD ne signifie pas remettre les tests d'acceptation aux développeurs. |
Acceptation TDD
Le développement piloté par les tests d'acceptation (ATDD) définit les critères d'acceptation et les tests d'acceptation lors de la création des User Stories, au début du développement. ATDD se concentre sur la communication et la compréhension commune entre les clients, les développeurs et les testeurs.
Les pratiques clés d'ATDD sont les suivantes -
Discutez de scénarios du monde réel pour construire une compréhension commune du domaine.
Utilisez ces scénarios pour arriver aux critères d'acceptation.
Automatisez les tests d'acceptation.
Concentrez le développement sur ces tests.
Utilisez les tests comme une spécification en direct pour faciliter le changement.
Les avantages de l'utilisation d'ATDD sont les suivants -
Les exigences sont claires et sans lacunes fonctionnelles.
D'autres comprennent les cas particuliers que prévoient les développeurs.
Les tests d'acceptation guident le développement.
TDD contre BDD
Selon Dan North, les programmeurs sont normalement confrontés aux problèmes suivants lorsqu'ils effectuent un développement piloté par les tests -
Où commencer
Que tester et quoi ne pas tester
Combien de tests en une seule fois
Comment appeler leurs tests
Comment comprendre pourquoi un test échoue
La solution à tous ces problèmes est le développement axé sur le comportement. Il a évolué à partir des pratiques agiles établies et est conçu pour les rendre plus accessibles et efficaces pour les équipes, novices dans la livraison de logiciels agiles. Au fil du temps, BDD s'est développé pour englober une vision plus large de l'analyse agile et des tests d'acceptation automatisés.
Le principal difference between TDD and BDD est-ce que -
TDD décrit le fonctionnement du logiciel.
D'autre part, BDD -
Décrit la manière dont l'utilisateur final utilise le logiciel.
Favorise la collaboration et la communication.
Met l'accent sur des exemples de comportement du système.
Vise les spécifications exécutables dérivées des exemples