Hi my name is Evan and I’m a behavior driven development addict.
My BDD habit began about a year and a half ago at RailsConf when Ben Scofield was first telling me about this awesome thing called RSpec. Since then, I’ve spent ever increasing time getting to know this BDD idea, largely through RSpec, but also by way of discussion with peers at conferences and over the net. Here’s what I’ve learned:
It’s not hocus pocus. It’s not black magic. It’s not a silver bullet.
Then WTF is BDD?
“Unfortunately, no one can be told what [BDD] is. You have to see it for yourself.”
Sorry. I couldn’t resist.
BDD is a technique to see your code from a different perspective
That’s all. Really.
Let’s talk about how we got here in the first place.
First there was pseudo code
And it was good. It was just little bits of descriptive text on a piece of paper, or maybe comments in your code, that allowed you to describe your intent in natural language instead of in a machine language.
Then there were unit tests
xUnit wasn’t the beginning. I was writing unit tests in plain ol’ C back in the mid-90s – as I’m sure that several of you were in your language of choice at the time. xUnit, thankfully, gave many of us a little more structure and a nice little generic tool for executing tests within that structure. Cool!
Then there was writing tests first
I first recall reading about this in Kent Beck’s first edition of eXtreme Programming eXplained. Sure, I tried it back in ‘99 and was mightily impressed with the results. Writing the tests first typically caused me to write less buggy code. Unfortunately, I couldn’t be “extreme” in the XP sense due to the ridiculous over-the-top insanely waterfall processes imposed on me by the government. Still, it was an interesting experiment for me.
However, this movement grew and grew and…
Then there was “Test Driven Development”
Wow! Clearly a technique has developed into something of consequence to many when it has been given a name! Smalltalk people were doing it. Java people were doing it. Practically everyone was doing it (including crazy Ruby people such as I’ve become)!
But some weren’t satisfied. A lot of people were writing tests first, which was really cool as it meant that more people were writing tests. However, there is more to TDD than writing tests firsts.
We need to “think different”
AppleFanboy.satisfied? # => true
The operative word here is “think”. Some folks were so caught up in the “testing” aspect of TDD that they missed another important part: testing as a design methodology (aka thinking about your code from a different perspective). From that dissatisfaction came BDD.
Bryan Liles points out, in his sublime Test all the fucking time talk, that TDD is BDD and anyone saying otherwise is lying. I could not possibly agree more.
But TDD/BDD should make you THINK
The reason that you should TDD/BDD is to rationally second guess yourself. I don’t care how talented of a code-flinging monkey you are or think you are: your code will be better for seeing it from a different perspective. TDD/BDD, by way of testing first, should cause you to consider the behavior that you are describing.
When you implement the code that makes your test or spec pass, again, you should ponder your creation.
You spec a little, you implement a little, perhaps realize something that you should have spec’d but didn’t (because you’re human and we don’t get everything right the first time), write that spec, write its implementation, rinse, repeat.
RSpec is just a tool that may help you with your TDD/BDD. As Bryan says, the tool is largely irrelevant (although nested contexts *do* kick major ass whichever tool provides them to you).
The point is that you should THINK all the fucking time
TDD/BDD is probably not the ultimate. After all, we started with pseudo code and, debatably, evolved up to TDD/BDD. I look forward to the next technique that will make me seem smarter than I really am.
Posted by evan on Nov 08, 2008