I've been hearing a lot about Behavior Driven Development ("BDD") in the last year. Up til now, I never understood what the real deal was, though. I always saw it as a different specification for a unit test and never really understood how TDD and BDD were different.
Jimmy Bogard changed that for me, with his post, Converting tests to specs is a bad idea (emphasis, his).
BDD is much more than naming conventions and the word "should", it's more about starting with a context, then defining behavior outside of any hint of an implementation.
...
But when writing true BDD-style specs, I don't care about the underlying class or method names. All I care about is the context and specifications, and that's it!
...
The key difference here is nowhere in the fixture nor the test method name will you find any mention of types, member names, or anything that hints at an implementation. I'm driven purely by behavior, which led me to a completely different design than my test-first design. In the future, if I decide to change the underlying implementation, I don't need to do anything with my BDD specs. When I've decoupled my implementation of behavior completely from the specification of behavior, I can make much more dramatic design changes, as I won't be bound by my tests.
I think the key here, and the real difference between TDD and BDD is the level of abstraction - separating the test, or behavior, specification from the implementation. This is very similar to the abstraction and separation that we strive for in OOA vs. OOD, Architecture vs. Implementation, Design Pattern vs. Design Implementation, etc, etc.
BDD has a tendency to specify the business rule and process (the 'behavior') in the test fixture name, test method name, and assertions. TDD on the other hand, tends to specify the class name, method names, and expected output in the test fixture, test methods, and assertions.
Thanks, Jimmy! Your experience and insight has opened a new world of questions and travels for my own development efforts. :)