Le développement piloté par les tests est une méthodologie de développement logiciel axée sur les tests, ce qui signifie qu'il faut écrire du code de test avant d'écrire le code réel qui sera testé. Dans les mots de Kent Beck:
Le style ici est d'écrire quelques lignes de code, puis un test qui devrait s'exécuter, ou encore mieux, d'écrire un test qui ne s'exécutera pas, puis d'écrire le code qui le fera fonctionner.
Après avoir compris comment écrire un petit morceau de code, maintenant, au lieu de simplement coder, nous voulons obtenir des commentaires immédiats et pratiquer "coder un peu, tester un peu, coder un peu, tester un peu". Nous écrivons donc immédiatement un test pour cela.
Ainsi, TDD est une méthodologie technique de bas niveau que les programmeurs utilisent pour produire un code propre qui fonctionne.
Le développement axé sur le comportement est une méthodologie qui a été créée sur la base du TDD, mais qui a évolué vers un processus qui ne concerne pas uniquement les programmeurs et les testeurs, mais qui traite plutôt avec toute l'équipe et toutes les parties prenantes importantes, techniques et non techniques. BDD est parti de quelques questions simples auxquelles TDD ne répond pas bien: combien de tests dois-je passer? Que dois-je tester et que ne dois-je pas tester? Lequel des tests que j'écris sera en fait important pour l'entreprise ou pour la qualité globale du produit, et lesquels ne sont que ma sur-ingénierie?
Comme vous pouvez le constater, ces questions nécessitent une collaboration entre la technologie et les entreprises. Les parties prenantes commerciales et les experts du domaine peuvent souvent dire aux ingénieurs quels types de tests semblent utiles, mais uniquement si les tests sont des tests de haut niveau traitant d'importants aspects commerciaux. BDD appelle ces tests de type professionnel des «exemples», comme dans «Donne-moi un exemple de la manière dont cette fonctionnalité doit se comporter correctement», et réserve le mot «test» aux vérifications techniques de bas niveau telles que la validation des données ou les tests d'intégrations d'API. La partie importante est que tandis que tests ne peuvent être créés que par des programmeurs et des testeurs, les exemples peuvent être collectés et analysés par toute l'équipe de livraison - par les concepteurs, les analystes, etc.
En une phrase, l'une des meilleures définitions de BDD que j'ai trouvée jusqu'à présent est que BDD consiste à «avoir des conversations avec des experts du domaine et à utiliser des exemples pour acquérir une compréhension commune du comportement souhaité et découvrir des inconnues». La partie découverte est très importante. Au fur et à mesure que l'équipe de livraison recueille de plus en plus d'exemples, elle commence à comprendre de plus en plus le domaine de l'entreprise et réduit ainsi son incertitude quant à certains aspects du produit qu'elle doit traiter. À mesure que l'incertitude diminue, la créativité et l'autonomie de l'équipe de livraison augmentent. Par exemple, ils peuvent maintenant commencer à suggérer leurs propres exemples que les utilisateurs professionnels ne pensaient pas possibles en raison de leur manque d'expertise technologique.
Maintenant, avoir des conversations avec les experts en affaires et dans le domaine sonne bien, mais nous savons tous comment cela se termine souvent dans la pratique. J'ai commencé mon parcours avec la technologie en tant que programmeur. En tant que programmeurs, on nous apprend à écrire du code - algorithmes, modèles de conception, abstractions. Ou, si vous êtes designer, on vous apprend à concevoir—Organisez les informations et créez de belles interfaces. Mais lorsque nous obtenons nos emplois d'entrée de gamme, nos employeurs s'attendent à ce que nous «apportions de la valeur aux clients». Et parmi ces clients peut être, par exemple ... une banque. Mais je ne savais presque rien sur les services bancaires, sauf comment réduire efficacement le solde de mon compte. Il faudrait donc que je traduise en quelque sorte ce que l'on attend de moi en code ... Je devrais construire un pont entre la banque et mon expertise technique si je veux offrir une valeur. BDD m'aide à construire un tel pont sur une base stable de communication fluide entre l'équipe de livraison et les experts du domaine.
Apprendre encore plus
Si vous voulez en savoir plus sur BDD, j'ai écrit un livre sur le sujet. "Rédaction de spécifications exceptionnelles" explore l'art de l'analyse des exigences et vous aidera à apprendre à créer un excellent processus BDD et à utiliser des exemples au cœur de ce processus. Le livre parle du langage omniprésent, de la collecte d'exemples et de la création de spécifications dites exécutables (tests automatisés) à partir des exemples, des techniques qui aident les équipes BDD à fournir des logiciels de qualité dans les délais et le budget.
Si vous êtes intéressé par l'achat de «Rédaction de spécifications exceptionnelles », vous pouvez économiser 39% avec le code promotionnel 39nicieja2 :)