BehaviourDrivenDevelopment

Un article de Agora2ia.

(Redirigé depuis BDD)


Le Behaviour Driven Development (ou BDD), ou programmation par contrat avec son DSL (DomainSpecificLanguage), se traduit par "Développement Piloté par le Comportement"...

Presque tous les langages objets ont leur DSL comme on peut le voir sur http://behaviour-driven.org/Implementations

Une "implémentation" est RSpec...


Discussion "Evolution de TDD" sur XP France

Point d'entré de la discussion sur le Yahoo group d'Xp France.

Grandes idées :

  • DSL : "je définis souvent des fonctions qui factorisent mes tests unitaires, donc je suppose que je pratique un prémisse du DSL."
  • BDD apporte une autre dimension au TDD : permet de décrire des actions de plus haut niveau que des tests de code.
    • Ainsi Le Product Owner peut les écrire lui même.
    • On a même commencer à étudier Concordion (pour générer du test auto à partir de "BDD like").
    • Avec BDD on peut décrire des tests plus orientés IHM (plus difficile à intégrer en TDD).
    • On a un historique de code de 7 ans sans test auto. : BDD plus facile pour écrire les "acceptance tests" des nouvelles User Stories
  • Concordion est une évolution de Fit mais pour l'instant que Java voir Ruby de supporté
  • "BDD on peut décrire des tests plus orientés IHM" : C'est peut-être du au fait que je fait beaucoup de web.
  • Je trouve cela abusif d'utiliser un nouveau terme et prétendre qu'il s'agit d'une évolution de TDD.
    • Les gens qui disent ça me semblent n'avoir pas compris TDD.
    • A la rigueur nouvelle génération de frameworks xUnit avec d'autres conventions stylistiques.
    • Dire qu'il s'agit d'une innovation d'utiliser "should" plutôt que "assert" est assez prétentieux (l'ancêtre de junit, sunit, en smalltalk,

utilisait déjà "should").

  • BDD sert aux tests du client :
    • Ce n'est pas une évolution de TDD, mais un outil pour les tests clients
    • Rien à voir avec le TDD.
    • Plutôt en concurrence avec les approches tabulaires (Fit) et les mini-langages utilisés depuis longtemps pour ces tests clients.
    • Je ne vois aucune difficulté à commencer à faire du TDD sur les nouveaux développement d'un vieux projet.
    • Je ne vois aucune difficulté à commencer à faire des tests clients Fit ou mini-langage pour les nouvelles features d'un vieux projet.
  • "difficulté à commencer à faire du TDD" : classes sont hyper couplées, sans interface, toutes dépendantes d'un objet magique "context"
  • En Java, pas trouvé d'outils efficaces pour les tests IHM : le BDD permet un formalisme de plus haut niveau
    • 3000 classes avec BD objet : 90% du code est interdépendant : le TDD est ici fonctionnel
    • En production depuis 6ans : ne peut pas refactorer les anciennes fonctionnalités que l'on étend maintenant sous prétexte de vouloir y mettre du TDD.
  • En swing, je vous conseille de concevoir vos tests vous même, sans "framework".
    • Swing est testable,
    • c'est formateur,
    • cela apprend la mécanique interne de swing,
    • cela favorise la réflexion, cela vous permet de réfléchir sur ce qui particularise votre IHM, etc.
  • Facile de commencer à faire du TDD, à condition d'en faire où c'est possible, et d'augmenter progressivement, au gré de petits remaniements

pertinents, la proportion du code où c'est possible.

    • On ne peut pas, par définition, "refactorer" (remanier) plusieurs semaines: au-delà de quelques minutes, exceptionnellement quelques heures, ce n'est plus du remaniement c'est de la refonte.