Is behaviour driven development about design or analysis?_问答_开发者

The more I read about BDD and how it is supposed to be improved TDD the more confusing it all seems to me. I've found quotes from expert that say it's about design, but also from other experts that say it's about analysis.

The way I currently see it is this:

1) analysis: BDD

from wikipedia

The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model.

So after BDD we have the requirements (s开发者_运维问答tories and the scenarios). But I'm not sure about the conceptual model part.

2) design: eg with tools like resonsibility driven design using CRC cards

3) code: coding the design, optionally use testing (like what they say about TDD done wrong, which I also find useful)

Am I wrong in how I see this? I'm having trouble seeing the forest through the trees at the moment.

In short it's to do with Analysis.

BDD is for "acceptance test driven development" - i.e. for knowing if a system under test behaves as expected for a specific user story scenario.

When I worked with Jbehave we used it at the user story level and still did "conventional" TDD for handling collaborations between individual objects and between subsystems.

Typically business systems use BDD scenarios to describe business domain behaviour not to test the tiny implementtion details inside the system. You want the BDD scenarios pitched at the domain expert's level of abstraction. Those scenarios wouldn't make much sense to domain experts and would be very fragile if they described every tiny detail of the implementation.

A BDD scenario says what the system should do for a user story but not how it does it.

BDD is about writing "executable specifications" or acceptance testing a.k.a. black-box testing which, by definition, takes an external perspective of the test object to derive test cases.

So BDD can't be about design, BDD is about testing features/stories/scenarii, BDD is closer to analysis.

BDD - Behaviour Driven Development

Behavior = ..in the context of.. Development - ...in the construction of...

Development in this case indicates to me that the analysis has been done and one is implementing something that is in the context of a specific behaviour.

so to answer the question, I beleive its in the Design.

I think from an architecture POV BDD would be about design. I need to design an application that can do something, that will later be used in acceptance testing. So, from the high-level design I want to make certain that I am designing for the various behavior requirements, so that I am not overdesigning, and limit duplication.

It helps with ensuring that we may not need to redesign as the user has has more time to think about what they actually want to see, how the application will perform.

BDD (or TDD for that matter) isn't about anything. It's a technique (in the case of BDD, more of an approach) that supports analysis and design (as well as that pesky little implementation step). You often hear the phrase "red, green, refactor" associated with TDD, and so it applies to BDD: create the test and see that it fails, make the test pass by updating the codebase, then rework the system into an improved form while you preserve the passing tests.

So BDD supports analysis when you create the tests: you should be describing the behaviour required in the form of tests or examples. It supports design when you run the tests: your design decisions are prevented from inadvertently breaking required behaviour, and can be guided by the analysis. But it doesn't do any of the analysis or design for you; you still have to think. It's a way of making sure that, during the analysis and design steps, you don't contradict yourself.

BDD and TDD even more have a very unlucky name because it doesn't actually cover what they are used for.

You don't want to write tests for every possible corner case during your dev cycle that is something testers should pick up.
You don't want regressions and you want to be sure you're writing the code you need to clear this iteration so you want a repeatable result
You don't have to do detailed designs at the start but rather jot some requirements down you want to see finished this time around.

BDD/TDD any of the 2 is fine if you don't write a line of code before you have a bit of code that describes the bit of code you're about to write. Doing that you'll get into a zone.
While there is no proof that BDD/TDD will improve your dev speed (most likely won't) it will greatly reduce the number of issues you get back after releasing the software which has been proven.

BDD is an evolution of TDD where TDD puts the pressure on to test everything BDD relaxes this and says that you should only test the public behavior of your classes because the internals are likely to change.

BDD is as much about design as it is about analysis, but I don't think that that is your question is it? You want to know how to translate the stories into flowcharts and architectural diagrams?

Because from what I get from your question is that you make a big design up front and then try to code that out. That won't work with BDD because whilst satisfying your stories which you should write in a piecemeal fashion your get your code and architecture automatically. It's called emergent design so there is no huge planning phase.

In a SCRUM or like wise system this works really well because the business prioritizes your stories. You start from the top and write a spec/example for it then try to satisfy the example repeating this until you've completed this backlog item and then pick up the next one and start over again.

I hope this answers your question.. if not you'll need to clarify a little because it's a braod topic. In short BDD is purely a developer tool, not for architects, BA's,... Testers may use the BDD tools but I hope that isn't the only tool they're using to test the application.