> BDD is not primarily a testing thing. You happen to get tests out of
> it afterwards, but there's usually still more testing that needs to be
> done. It's much more about developing an understanding of what you're
> about to produce.

> This is at odds with the way in which most people do and think about
> BDD, so if you can help me fix that, it would be great.

> There is a definition of BDD; it just isn't widely available. Here it is:

> “BDD is a 2nd generation, outside-in, pull-based,
> multiple-stakeholder, multiple-scale, high-automation, Agile
> methodology. It describes a cycle of interactions with well-defined
> outputs, resulting in the delivery of working, tested software that
> matters.”
>    - Dan North, 2009

> Turns out that the strangest bit of BDD is that phrase,
> "well-defined". Actually getting to that - and discovering the bits
> you don't know about - is at the heart of BDD. The trouble with using
> the word "test" when you do this is that everyone assumes you know
> what it is you're testing, which of course, you don't. Hence the
> "Given, When, Then" and other language, which help you have the
> conversation with stakeholders and find out what's missing.

> Except, of course, that there's always things you don't know you don't
> know, hence the need for the fast feedback loops, especially
> incremental releases.

> Here's one of Dan's latest posts on the discovery aspect of BDD
> (except it's bigger than BDD):

> http://dannorth.net/2010/08/30/introducing-deliberate-discovery/

> Hope that helps. If you want something prescriptive, here's some rules
> to follow:

> - Assume you've got it wrong.
> - Have conversations to find out how wrong.
> - When you know enough to get feedback on the rest, implement and release.
> - Assume you've got it wrong.

> If you like, you can use BDD tools to do that 2nd bit, which will
> result in some nicely automated scenarios.

> Cheers,
> Liz.

> On Fri, Jan 28, 2011 at 10:14 PM, Johnno Nolan <johnnono...@gmail.com>
> wrote:
> > I've been observing  the movement of BDD for a while now. (and
> > implementing aspects) but the whole concept is a teeny bit wooly.
> > I'm gonna talk about it at my local user group. We're going to try and
> > define what we think BDD is.

> > Here are some observations I can think of which I will try and get the
> > group specify the meaning of.

> > It's a testing thing,
> > It's a methodology.
> > It's given when then
> > It's all behaviour.
> > It's feature injection.
> > It's pull based.
> > It's outside-in.

> > Are there anymore observations? Is anything in there that should be
> > talked about with respect to BDD?
> > Why is there no definition of BDD, nothing prescriptive?

> > I want to answer these questions I'm hoping the members of this group
> > can give me some input to make the session useful.
> > So if anyone has any input it would be much appreciated.

> > regards

> > John[no]

> > --
> > You received this message because you are subscribed to the Google Groups
> "Behaviour Driven Development" group.
> > To post to this group, send email to
> behaviordrivendevelopment@googlegroups.com.
> > To unsubscribe from this group, send email to
> behaviordrivendevelopment+unsubscribe@googlegroups.com<behaviordrivendevelo pment%2Bunsubscribe@googlegroups.com>
> .
> > For more options, visit this group at
> http://groups.google.com/group/behaviordrivendevelopment?hl=en.

> --
> Elizabeth Keogh
> l...@lunivore.com
> http://lizkeogh.com
> http://lunivore.com

> --
> You received this message because you are subscribed to the Google Groups
> "Behaviour Driven Development" group.
> To post to this group, send email to
> behaviordrivendevelopment@googlegroups.com.
> To unsubscribe from this group, send email to
> behaviordrivendevelopment+unsubscribe@googlegroups.com<behaviordrivendevelo pment%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/behaviordrivendevelopment?hl=en.