Des histoires de réussite BDD là-bas?

Question

Après avoir écrit un petit article sur BDD, j'ai reçu des questions de personnes. demandant s'il y a des cas d'utilisation à grande échelle de BDD (et en particulier de NBehave).

Ma question s'adresse donc à la communauté: avez-vous un projet utilisant BDD avec succès? Si oui, quels avantages avez-vous obtenus et quels auraient pu être meilleurs? Souhaitez-vous refaire BDD? Le recommanderiez-vous à d'autres personnes?

Answer 1

Nous avons utilisé un peu BDD au niveau du code dans différents scénarios (projets Open Source et ND).

1. Indiquer à la vue dans le scénario MVC le type d'entrée à accepter de l'utilisateur ( Validation de l'interface utilisateur basée sur les règles DDD et. dans .NET)

   result = view.GetData(
     CustomerIs.Valid, 
     CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
   

2. Informer la couche de service du comportement de gestion des exceptions ( ActionPolicy est injecté dans les décorateurs):

   var policy = ActionPolicy
     .Handle<WebException>()
     .Retry(3);
   

L’utilisation de ces approches a considérablement réduit la duplication de code et rendu la base de code plus stable et flexible. De plus, cela simplifie les choses, grâce à l’encapsulation logique de détails complexes.

Answer 2

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 comme des comportements utilisant un DSL. Nous ne nous sommes pas lancés dans la conception initiale de comportements, mais nous en avons créé un grand nombre et les avons utilisés exactement comme vous le feriez pour des tests.

Comme vous vous en doutez, cela a beaucoup fonctionné comme un TDD, généralement bon. Formuler les tests comme des comportements était agréable lors des interactions avec les clients et constituait un document assez décent, mais je souhaite que les comportements soient écrits en anglais et que les tests soient programmés au lieu d'essayer de créer un langage intermédiaire difficile qui ne fonctionne pas convient parfaitement à l'un ou l'autre objectif.

Ce serait toujours BDD, juste sans cette jolie astuce consistant à essayer de tordre le langage en un langage défini par un style aléatoire. 100% satisfait.

Le site étant disponible et entièrement opérationnel, je dirais que c'est un succès: Découvrez

Answer 3

J'ai récemment utilisé le style BDD de GWT dans un document d'exigences de haut niveau. Je n'ai pas eu de retour d'informations sur le GWT de la part du client. Mon patron m'a dit qu'il l'aimait car il était très clair et facile à comprendre. Notez qu'il n'a aucune connaissance de BDD que je sache. Je n'ai pas mis de récits d'utilisateurs car cela aurait probablement été une fée un peu trop aérée pour les personnes ayant une cascade traditionnelle. Peut-être que je vais essayer de mettre des histoires d'utilisateurs la prochaine fois.

Au fait, ce n’était pas un projet d’interface utilisateur. Il s’agissait d’un projet d’intégration synchronisant les données d’un service Web dans une base de données. Donc, cela montre que GWT fonctionne même pour les non-yeux balles " UI.

Answer 4

J'ai utilisé le style Context-Specification sur plusieurs projets (à l'aide de MSpec) avec beaucoup de succès. J'essaie encore de comprendre les avantages réels du style Scénario. Plus j'utilise le style de spécification de contexte, plus je l'aime et plus les applications sont resserrées.