At its heart, BDD is about rethinking the approach to [[unit testing]] and [[acceptance testing]] in order to avoid issues that naturally arise. For example, BDD suggests that unit test names be whole sentences starting with a conditional verb ("should" in English for example) and should be written in order of business value. Acceptance tests should be written using the standard agile framework of a [[user story]]: "AsBeing a [role/actor/stakeholder] I want a [feature/capability] soyielding thata [benefit]". Acceptance criteria should be written in terms of scenarios and implemented asin classes: [[Given-When-Then|Given [initial context], when [event occurs], then [ensure some outcomes] ]].
Starting from this point, many people developed BDD frameworks over a period of years, finally framing it asin terms of a communication and collaboration framework for developers, [[quality assurance|QA]] and non-technical or business participants in a software project.<ref>{{Cite web |url=http://forums.pragprog.com/forums/95/topics/3035 |title=The RSpec Book – Question about Chapter 11: Writing software that matters |access-date=2009-08-09 |archive-url=https://web.archive.org/web/20091107220359/http://forums.pragprog.com/forums/95/topics/3035 |archive-date=2009-11-07 |url-status=dead }}</ref> During the "Agile specifications, BDD and Testing eXchange" in November 2009 in London, Dan North<ref>Dan North: [http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business How to sell BDD to the business] {{Webarchive|url=https://web.archive.org/web/20101125022509/http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business |date=2010-11-25 }}</ref> gave the following description of BDD:
<blockquote>
BDD is a second-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.</blockquote>
