I agree, there is definitely a growing group of people who do use BDD at the lower levels and don’t seem to believe in the scenario/story driven approach.

When we come down to low-level design, it’s not enough to drive the desired behavior and hope that results in enough tests to cover the space. If we’re practising evolutionary design, then we need tests as a pool of change detectors to aid in refactoring. I find this statement not to be enough: “My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose.” My goal is to be able to deliver such a system regularly and indefinitely, which implies not only having the right behavior, but also having low cost of maintenance, and the less easily I can refactor, the more the marginal cost of a feature rises. I write tests to ward off project heat death, and I’m concerned that if we abandon tests entirely, we will lose that intention.

So it seems to me that the choice of BDD or Story Test-Driven Development is largely one of taste and style. As you write, teaching the concepts without the word “test” have their definite benefit; however, I imagine that if we tell programmers to specify behaviors and not write tests, we’ll lose something valuable indeed. It may be that we need to teach them BDD first, but I don’t think we should breed the desire for testing out of them.——(1) I prefer everyone on the team be involved in analysis, but I recognize how rare that is.

I understand this style of development/design, especially if you focus on collaborations/interactions. Having said that I’m not sure that the resulting specifications are good examples of usage, or at least I’m not sure they will then act as good acceptance criteria.

So what I’m really wondering is how you make BDD work practice?

I’m certainly coming to my own understanding of BDD but I’m finding it hard to get a good understanding of the best way to do use it.