Après avoir écrit un small article sur BDD, j'ai reçu des questions de personnes demandant s'il y avait des cas d'utilisation à grande échelle de BDD (et spécifiquement NBehave). Donc, ma question va à la communauté: avez-vous un projet qui a utilisé BDD avec succès? Si oui, quels avantages avez-vous obtenus, et qu'est-ce qui aurait pu être mieux? Souhaitez-vous refaire BDD? Le recommanderiez-vous à d'autres personnes?Des histoires de réussite BDD là-bas?
Nous avons utilisé un peu de BDD au niveau du code dans différents scénarios (open source et projets ND).
Raconter la vue dans le scénario MVC, quel type d'entrée pour accepter de l'utilisateur (DDD and Rule driven UI Validation in .NET)
result = view.GetData(
CustomerIs.Valid,
CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
Raconter la couche de service, sur le comportement de la gestion des exceptions (ActionPolicy est injecté dans les décorateurs):
var policy = ActionPolicy
.Handle<WebException>()
.Retry(3);
L'utilisation de ces approches ha s une duplication de code extrêmement réduite, a rendu le code plus stable et flexible. De plus, cela rend tout plus simple grâce à l'encapsulation logique de détails complexes.
J'étais dans une petite équipe qui utilisait BDD sur un site Web. La façon dont nous l'avons utilisé était essentiellement TDD, mais les tests sont simplement écrits en tant que comportements utilisant un DSL. Nous ne nous sommes pas lancés dans une large conception initiale de comportements, mais nous en avons créé un grand nombre, et nous les avons utilisés exactement comme vous le feriez pour des tests.
Comme vous pouvez vous y attendre, cela a fonctionné beaucoup comme TDD, généralement bon. Le fait de qualifier les tests de comportement était agréable quand on interagissait avec les clients et constituait un document assez décent, mais j'aurais aimé que les comportements soient écrits en anglais et que les tests soient programmés au lieu d'essayer de trouver un langage intermédiaire difficile. s'adapter à l'un ou l'autre objectif parfaitement. Il serait encore BDD, juste sans cette astuce mignonne d'essayer de tordre la langue dans un langage délimité par un random_looking.set of_Punctuation plutôt que simple.spaces, mais ce n'était que mon attitude grincheuse-programmeur, tout le monde était 100% heureux avec.
Le site est disponible et pleinement opérationnel, donc je l'appellerais un succès: Have a look
J'ai récemment utilisé le style BDD de GWT dans un document d'exigences de haut niveau. Je n'ai pas eu de commentaires sur le GWT du client acheter mon patron a dit qu'il l'a aimé car il était très clair et facile à comprendre. Notez qu'il n'a aucune connaissance de BDD que je connais. Je n'ai pas mis dans les histoires d'utilisateur car cela aurait probablement été une fée un peu trop aérée pour les personnes avec un fond de cascade traditionnel. Peut-être que je vais essayer de mettre des histoires d'utilisateurs la prochaine fois. Par ailleurs, ce n'était pas un projet d'interface utilisateur. Il s'agissait d'un projet d'intégration synchronisant des données d'un service Web dans une base de données. Cela montre que GWT fonctionne même pour les interfaces utilisateur non "eye ball".
J'ai utilisé le style Context-Specification sur plusieurs projets (en utilisant MSpec) avec beaucoup de succès. J'essaie toujours de comprendre les vrais avantages du style Scénario. Plus j'utilise le style de spécification de contexte, plus je l'aime et plus mes applications sont ressenties.