Behavior Driven Development (BDD) is not a revolution in software design, but rather an evolution in how we software engineers think about program design. BDD was born from the observation that most developers were not realizing the full potentialof test-driven development (TDD). Many people say that TDD, done well, is not about testing but about design. However, the language of "testing" impedes novices and journeymen from realizing its full potential. In this article I will introduce Behavior Driven Development, explore the rationale behind it, and introduce Open Source tools—some new, some familiar, that you can use to get you started.
Extreme Programming (XP) popularized the concept of Test Driven Development a sa response to the reality that developers never seemed to have time to write unit tests. In response, taking developer testing to the extreme (pun intended), XP tells us to write tests before the code. The pattern: write a failing test; then write the code to satisfy that test; lather, rinse, and repeat.
As TDD practitioners have refined their art, the TDD community came to the realization that the real benefit of TDD it not about testing -- it is about design. Done well, TDD is a tool for creating supple, testable, and decoupled designs between collections of collaborating classes. However, the majority of developers practicing TDD have not made this mental leap. People started wondering why.
The Evolution of the TDD Developer
The path to enlightenment for a developer starting to practice TDD typically follows a pattern.  She,
- Starts using a unit testing framework; such as JUnit or NUnit.
- Starts gaining confidence in the code due to the existence of tests. Code can be refactored with impunity.
- Starts writing tests before the code.
- Realizes that tests, both hers an others, can be used as documentation for code.
- Begins writing tests first to design the class API.
- Realizes that by writing tests first, she is specifying the behavior of the class.
- Discovers the full potential of TDD by specifying interactions between collaborating objects by using mocks.
These last steps are truly the "Ah-ha!" moment of TDD.
Viewing the unimplemented class through the lens of a test, you realize that specifying the externally visible behavior of your class before the implementation allows you to define the behavior of your class. Definition of class behavior and interaction with collaborating classes is design. During this process questions can be asked about this class and its collaborators: Is this class doing too much? Too little? What are the externally visible behaviors of this class?
What impedes the developer from reaching this elevated level of software development? Two things. How we think about the problem of "testing" and the tools we use.
Language is the Leverage
Sapir and Whorf were American linguists in the lsquo;30s who developed the Sapir-Whorf Hypothesis. One of the principles of the hypotheses, the linguistic determinism principle, asserts that language determines the way we think, that is,
"There is a systematic relationship between the grammatical
categories of the language a person speaks and how that person both
understands the world and behaves in it." 
Which is to say, the language we use affects how we think about the world.
This language of testing is given to us by the tools, namely xUnit. The classes we create are called 'Test' cases. Collections of test cases are 'Test' suites. Methods must begin with the word 'test.’  The very word 'testing' implies an activity that happens last. From the dictionary 'testing' is defined as:
"To take measures to check the quality, performance, or
reliability of (something), esp. before putting it