04.04.08
About That BDD Example…
Much to my surprise, blogging is hard. It’s not the research and it’s not the writing: my problem is consistency. You see, I’d rather not waste your time nor mine if I really don’t have anything interesting to say. And then, sometimes, I simply find it hard to find a good anchor point out of the research that I am performing.
I thought I had a great anchor point in BDD. I really like the idea of the Test-First approach to software development being focused on behavior. When I teach TDD in the classroom, it is the concept that I repeat the most. Focus on behavior. It’s the right thing to do. And I like the fact that BDD makes the focus on behavior patently obvious. Yet, once I started digging into BDD it felt… awkward. At first, I assumed this was simply due to my lack of experience in this new approach, but the feeling didn’t go away. I couldn’t put my finger on what was wrong until I ran across Dave Thomas’ blog post on BDD.
When I evaluate tools or languages I look, primarily, for two qualities:
- Conciseness
- Elegance
I realize our discipline does not lend itself to either, and I think that is why I place so much importance on them. Coming up with a convoluted, high-ceremony, complex solution is easy. Because they don’t come naturally, coming up with a concise, elegant solution is hard work. And therein lies the problem with BDD: it is neither concise nor elegant – quite the opposite. The emphasis on attempting to provide a “plain english” syntax makes the tool verbose and unwieldy.
Does this mean we should stop exploring BDD? I don’t think so. It simply means the approach still needs a lot of work and some time to grow up; evolve. So, for now, I’m happy to stick with xUnit… with an eye toward BDD’s progression. It’s a bit of an anti-climax, I know, but sometimes life is like that.
