I went to pyconfr this year and attend a talk about bdd with behave by chbrun. After the talk, I felt disappointed since I know about it for a while now without practicing at work and I'm waiting for successful return of experience of bdd applied on a whole project. Since then, I feel the urge to write about it and I have material for 2 posts, one on the principles and one on the practices. I'll start with the principles.
Behavior Driven development, or bdd, is a concept proposed by Dan North. It came from a reflection about TDD which, according to Dan, semantically lead to bad development practices. By its name, TDD seems to be a testing practice. Actually, it is not. So called testing code is rather a runnable specification for software under development. Non regression test suite is a by-product, an argument that sells the practice to your project manager.
Consider TDD provides a specification. The problem is that it is written in code. Even with the cleanest code, it's a barrier for non developers. You got the idea: there is room for TDD improvement to make it communicate system specification to the WHOLE team. It's called BDD.
BDD is not about parsing regexes to produce test cases. BDD is not about system testing from GUI to database. BDD is not about replacing asserts by shoulds. BDD is about making runnable specifications, formerly known as unit tests, understandable for average Joe.
Next time, I'll write about practices and tools. When problems begin.
