I've had the good fortune to listen to Dan North a couple of times, formally and informally, when he talks about his passion, BDD. Even though I've heard him many times explain the concept, read numerous posts and played around with it, I can't say that I grasp the full story yet. But some things I do get.

First of all, there is a diversity in the BDD community on what it really means. In one corner there is the initial ideas from Dan and in the other corner there is variations of the concepts like SpecUnit from Scott Bellware.

But the basic idea is the same: Wording is important.

Dan derives his work from one of his greatest fascinations, Neuro-lingustic  programming (NLP) where words are used in a communication to trigger responses and effects from a party. His fascination with NLP in combination with having to explain TDD over and over again made him think about the wording and made him think about how words are important when building test-first kind of applications.

One of the words that is important is "Test" as in "Test Driven Development" where people often associate testing as something that is done after development. This is one of the controversies when it comes to selling TDD to the masses, "How can I write my test when I don't have something TO test".

Changing the name from "test" to "specification" or "behavior" will probably level the field.

Everyone specifies behavior of what they want before they try to build it (well almost everyone) so SDD, specification driven development, or as it's called BDD, will make more sense to people and is something they can relate other activities to.

This is where I think that the TDD community would do themselves a big favor if they started talking more about "specifying what the completed code should do", rather then "writing tests for the completed code before completing the code".

The BDD community talks a lot about wording in other senses as well. Dan for instance wants developers to make sure that the tests are complete sentences and sentences that matches requirements from the business. For instance:

Account_Should_Be_debited_Given_The_Account_Is_In_Credit_When_Customer_Requires_Cash

Is a name inspired by his "Given, When, Then" template for behavior specification.

To support this kind of naming scheme, the names tend to get long, projects has started, like the mentioned SpecUnit, RBehave, JBehave and NBehave. This is what the community is thinking about now. To support this new style of development we need new tools, the old once support TDD and not BDD and how should those tools look like?

So is BDD a hype or a paradigm shift? I believe it's the latter, I think that what the BDD and various spec* communities has started is an inevitable change of the "test-first" kind of coding. We see some small ripples now in how people design their tests but give it time and we'll see big changes in tooling and methodology. 

--

NLP: http://en.wikipedia.org/wiki/Neuro-linguistic_programming

Merlin's magic spells in modern projects: https://lowendahl.net/showShout.aspx?id=200

Dan's "Introducing BDD": http://dannorth.net/introducing-bdd

Scott on BDD: http://www.code-magazine.com/Article.aspx?quickid=0805061

JBehave: http://jbehave.org/

NBehace: http://nbehave.org/

Rbehave: http://dannorth.net/2007/06/introducing-rbehave