This past September, I attended VT Code Camp and gave a presentation on the exploration that my engineering team had done with Behavior Driven Development (BDD) which is a software development process that focuses on specifying behavior instead of writing tests.
Roughly two years ago we received some copies of The Art of Agile Development to read and discuss. As we went through it we opted to give XP a go and chose to try BDD as part of the process. In my presentation I focused on why we chose to do BDD, what tools we used, and how we felt it went.
In hindsight, there were some details missing from my presentation that would help people new to BDD understand how everything works together. Thankfully, people asked a ton of questions and the missing pieces were filled in.
Even better, was that some of the people in the audience had experience with BDD and we were able to speak of some additional concerns. The biggest being that BDD adds some overhead to your development. If you don’t have people consuming the output, mostly likely product owners, testers, or other non-developers on the team, then you’ll likely want to find another way of dealing with functional testing.
In summary of the presentation – doing BDD has been a little bit of a mixed bag. Its been great to have the functional tests as we’ve gone along and being run as part of our builds. On the flip side we haven’t been able to bring them into the discussions with business stake holders. Specifically, I’d like to see the language used for cucumber start to make it’s way into the acceptance criteria of our user stories. I’m still pro-BDD and trying to expand it’s usage.