Le développement axé sur le comportement concerne-t-il la conception ou l'analyse?

Question

Plus je lis au sujet de BDD et de la manière dont il est censé être amélioré, plus cela me semble confus. J'ai trouvé des citations d'experts qui parlent de design, mais également d'autres experts qui parlent d'analyse.

Voici comment je vois les choses:

1) analyse: BDD

de wikipedia

  

Résultat de l'analyse orientée objet   est une description de ce que le système est   fonctionnellement nécessaire pour faire, dans le   forme d'un modèle conceptuel.

Donc, après BDD, nous avons les exigences (histoires et scénarios). Mais je ne suis pas sûr de la partie modèle théorique.

2) conception: par exemple avec des outils tels que la conception basée sur la responsabilité utilisant des cartes CRC

3) code: coder la conception, éventuellement utiliser des tests (comme ce qu'ils disent à propos du TDD mal fait, ce que je trouve également utile)

Est-ce que je me trompe dans ma façon de voir cela? J'ai du mal à voir la forêt à travers les arbres en ce moment.

Answer 1

En bref, il s'agit de Analyse .

BDD est destiné au "développement piloté par les tests d'acceptation". - c’est-à-dire pour savoir si un système testé se comporte comme prévu pour un scénario de scénario utilisateur spécifique.

Lorsque j’ai travaillé avec Jbehave, nous l’avions utilisée au niveau de la user story et nous faisions encore "conventionnel". TDD pour la gestion des collaborations entre objets individuels et entre sous-systèmes.

Généralement, les systèmes d’entreprise utilisent des scénarios BDD pour décrire le comportement du domaine d’activité, et non pour tester les détails de mise en œuvre au sein du système. Vous voulez que les scénarios BDD soient définis au niveau d'abstraction de l'expert du domaine. Ces scénarios n’auraient aucun sens pour les experts du domaine et seraient très fragiles s’ils décrivaient chaque détail de l’implémentation.

Un scénario BDD indique ce que le système devrait faire pour une user story , mais pas comment il le fait.

Answer 2

BDD concerne l’écriture des "spécifications exécutables". ou test d'acceptation aka le test de la boîte noire qui, par définition, prend perspective externe de l'objet de test pour dériver des cas de test .

Pour que BDD ne puisse pas être axé sur le design, BDD consiste à tester des fonctionnalités / histoires / scénarios, BDD se rapprochant de l'analyse.

Answer 3

BDD - Développement basé sur le comportement

Behavior = ..dans le contexte de .. Développement - ... dans la construction de ...

Dans ce cas, le développement indique que l'analyse a été effectuée et que l'on implémente quelque chose qui se situe dans le contexte d'un comportement spécifique.

donc pour répondre à la question, je crois que c'est dans la conception .

Answer 4

Je pense qu’en architecture POV BDD, ce serait une question de design. Je dois concevoir une application capable de faire quelque chose, qui sera utilisée plus tard pour les tests d'acceptation. Donc, de la conception de haut niveau, je veux m'assurer que je conçois pour les différentes exigences de comportement, afin de ne pas trop concevoir, et de limiter les duplications.

Cela aide à éviter toute refonte de la conception, car l'utilisateur dispose de plus de temps pour réfléchir à ce qu'il souhaite réellement voir, à la performance de l'application.

Answer 5

BDD (ou TDD d'ailleurs) n'est pas pour . Il s’agit d’une technique (dans le cas de BDD, plutôt d’une approche) qui prend en charge les conceptions d’analyse et (ainsi que cette petite étape de mise en œuvre fastidieuse). Vous entendez souvent la phrase "rouge, vert, refactor". associé à TDD et s’applique donc à BDD: créez le test et constatez son échec, faites passer le test en mettant à jour la base de code, puis retravaillez le système sous une forme améliorée tout en préservant les tests réussis.

BDD prend donc en charge l’analyse lors de la création des tests: vous devez décrire le comportement requis sous forme de tests ou d’exemples. Il prend en charge la conception lorsque vous exécutez les tests: vos décisions de conception sont empêchées de rompre par inadvertance le comportement requis et peuvent être guidées par l'analyse. Mais il ne fait aucune des analyses ou de la conception pour vous; il faut encore réfléchir. C’est une façon de s’assurer que, lors des étapes d’analyse et de conception, vous ne vous contredisez pas.

Answer 6

BDD et TDD ont encore plus un nom très malchanceux car ils ne couvrent pas réellement l'usage auquel ils sont destinés.

• Vous ne voulez pas écrire de tests pour tous les cas possibles pendant votre cycle de développement, c'est quelque chose que les testeurs devraient prendre.
• Vous ne voulez pas de régressions et vous voulez être sûr d'écrire le code dont vous avez besoin pour effacer cette itération afin d'obtenir un résultat répétable
• Vous n'avez pas besoin de faire des conceptions détaillées au début, mais notez plutôt certaines exigences que vous voulez voir terminées cette fois-ci.

BDD / TDD n’importe lequel des 2 convient si vous n’écrivez pas une ligne de code avant d’avoir un morceau de code décrivant le morceau de code que vous êtes sur le point d’écrire. En faisant cela, vous entrerez dans une zone.
Bien qu'il n'y ait aucune preuve que BDD / TDD améliorera votre vitesse de développement (cela ne le sera probablement pas), cela réduira considérablement le nombre de problèmes que vous obtenez après la publication du logiciel qui a fait ses preuves.

BDD est une évolution de TDD où TDD met la pression sur tout pour le tester. BDD détend cela et dit que vous ne devez tester que le comportement public de vos classes, car les éléments internes sont susceptibles de changer.

BDD est autant une question de conception que d’analyse, mais je ne pense pas que ce soit votre question. Vous voulez savoir comment traduire les histoires en organigrammes et en diagrammes architecturaux?

Parce que, d'après ce que je comprends de votre question, vous réalisez un gros dessin à l’avant, puis vous essayez de le coder. Cela ne fonctionnera pas avec BDD car, tout en satisfaisant vos histoires que vous devriez écrire de manière fragmentée, vous obtenez votre code et votre architecture automatiquement. C'est ce qu'on appelle la conception émergente, il n'y a donc pas de phase de planification énorme.

Dans un système SCRUM ou similaire, cela fonctionne très bien car l’entreprise donne la priorité à vos histoires. Commencez par le haut et écrivez un spéc / exemple pour cela, puis essayez de satisfaire cet exemple et répétez-le jusqu'à ce que vous ayez terminé cet élément de l'arriéré, puis prenez le suivant et recommencez.

J'espère que cela répond à votre question. Sinon, vous devrez clarifier un peu car c'est un sujet difficile. En bref, BDD est purement un outil de développement, pas pour les architectes, les BA, ... Les testeurs peuvent utiliser les outils BDD mais j'espère que ce n'est pas le seul outil qu'ils utilisent pour tester l'application.