[edited: fixed some typos]
I believe Dan North was the first to use the term BDD (Behavior-Driven Development). In his post , Introducing BDD, he describes the creation of BDD as a methodology to promote good TDD and help avoid it's pitfalls. In another post, What's in a Story?, he states:
Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes.
Since my last post on BDD, I've been experimenting with this methodology. One of the things I've learned is that this can be applied to high level acceptance tests and all the way down to the unit tests (should I say spec instead of test?). I think the goal is the same at any level; you define the behavior then you implement it.
In Dan's post, Goal-oriented vocabulary - saying what you mean, he talks about using
... goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.
This is very interesting to me and I think it helps me solidify BDD even more. Historically I've written tests around the tasks the objects were trying to perform in the system. I realize now that even though I was writing tests first, I wasn't really letting it drive my development. I was thinking "I need this object to do foo" instead of "I need to do foo, now how do I implement it?". More recently, I have been working to change the way I think by working "outside-in". I'm using the BDD style language as a tool to help me stay on track. One of the things that I've learned is that this takes practice and discipline. Working with a pair is really beneficial here because you can help keep each other out of the weeds.
Colin Jack raised a good question in a recent post on how detailed do you make BDD tests (ugh, I mean specs). He brings up the point that if you make the tests too detailed, you may end up testing the same things at multiple levels. I believe this is ok because the specs (yes! - not tests) are not only a tool to validate your development, but also a tool to guide it. Dan validates to me that BDD is not just a high level testing methodology by saying:
You start at the outside with an automated scenario, and work inwards, discovering services and collaborators as you go, until you’re done.
For awhile now, I've been bothered by some tests being too coupled to their implementation. I've now come to accept that if you use tests to drive your development, you will have some tests that are coupled to implementation at the low levels. I became ok with this once I decided that it's ok to throw tests away. If I'm making a change that is breaking a lot of tests, then I probably need to be writing new tests that are driving that development and deleting the ones that don't make sense anymore. Using BDD and working outside-in, I have more freedom to change implementation at different levels because I have the spec validation at the higher levels.
I'm still discovering BDD and I know that I have a ways to go before I'm confident in saying that I know what it is.