I don't know much about BDD (Behavior-Driven Development) but I've been collecting a few clues and it sounds interesting. I always lose that newbie perspective after learning something new, so I thought it would be nice to write a series of posts that document my journey of understanding to what it's all about. Hopefully by the end I'll know what the hell is going on and will have collected enough information to help out some other folks down the road.
I thought I'd start off by googling "BDD". Several of the links were referring to a mental disorder and that made me think that I should point out that this post is not about a mental disorder (or at least I don't think it is).
I know that BDD is related to TDD, so I googled "BDD TDD" and came across a video of Dave Astels giving a talk about BDD. In the video he explains that TDD is really about design and not testing. He states that
"BDD is what you are doing already if you are doing TDD very well."
He also goes on to explain that most people aren't doing it well and that one reason could be that people are working in a distracted mind set because they are looking at it from a testing point of view instead of a design point of view. I have to say that I think in a testing mind set when I'm doing TDD, so I probably fall into that category of folks that are not doing it well. He goes on to explain that xUnit type tools influence us to think in those terms of testing. A way to free yourself up to think differently is to use tools that change the language of tests to be more focused on testing the behavior instead of testing classes. Does that mean that we're really doing the same things as TDD, but just calling it something different and looking at it from a different perspective? I don't think so (unless you're already doing TDD well). I think there is more to it than that.
I recently read Jimmy Bogard's post Converting tests to specs is a bad idea which really made some things click in my head. Jimmy says:
"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."
and
"... 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!"
After reading that, I think I'm starting to get it. I've always felt that my tests have been too close to my implementation because of the friction sometimes faced with refactoring a design. If my tests mirror my design, then I have to refactor the structure of my tests when my design changes which can be a PITA. You can solve a problem several different ways, but your test should be organized and structured according to the behavior of the system instead of a specific implementation.
I'm sure that I'll gain a better understanding of BDD as time goes on and I tend to share that information here.