Behaviour Driven Development

The company I work for has been using BDD for over 2 years right now. I think it would be good to define what BDD means for us (as possibly BDD is similar to Agile in a way that you'll have hard time finding two people for whom it means the same). Couple of points that visualise our mindset:

1. We do not add feature, we add an ability so our product is able to act under certain, new circumstances (obviously we first need to understand the business context/circumstances from much wider perspective then previously)
2. Since we understand business much better (we have small business trainings at the beginning of working on every new user story - it was difficult at the very beginning as there was much to learn - it's much easier today) it is much easier for us to think about different business border cases and still being engineers we come up with cases that non-engineer would rather not come up with which usually also ends up as separate examples.
3. We do not have business documentation as we fill up so called system tests with bunch of examples how our system behaves under certain circumstances - after these two years I can say that for us this is the most difficult part (there are certain traps waiting for thee one that will tray to follow this path - I will write about them later on)
4. We have also introduced BDD on unit test level (discussion under this blog post describes what it means quite well: http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/)

 
There are a few tools that support BDD (ex. JBehave, Cucumber), I can tell about JBehave only as this is the only tool we've been using, nevertheless I believe that whichever tool you choose, problems you'll encounter will be similar.

JBehave is just a tool and at some point in time we realized that we've hurt ourselves with it - we simply used it in a wrong way. I will write just short sentences but you must know that behind each sentence there was blood and sweat:

1. JBehave is an overhead - you suddenly need to maintain twice as many files (story + implementation). Use it only if someone will be reading story files, only if it truly be treated as documentation. If this is not going to be the case, think what is it that you want to achieve with JBehave because there is a price that you going to pay.
2. Think twice before you'll use JBehave on lower (then system tests) test levels. Our experience showed that JBehave is great to visualise some main concepts in the software (main paths through the SW) but it is not the best tool to explain some complicated and-or-or-and-and logic as in order to understand the core of such logic you need to grasp multiple stories at once which is really difficult.
3. Examples alone are sometimes not enough - JBehave gives a special key word ("narrative") to add some context but in our case we needed to add more description of a context then it seemed intuitive at the beginning (after couple of months we found ourselves in quite usual situation when something that what obvious some time ago is not so obvious anymore)
4. Do not use technical language - at the end of the day it is to be read by Business guys and they are not really interested in XPaths or threads
5. Hope that Uncle Bob won't have anything against it that i'll quote him as a fifth point: “You don’t get a special license to write a highly coupled tests just because you’re doing BDD” by R.C. Martin

Fifth point is taken from the discussion that took place under Dan North's blog post I've already mentioned in this post.

I hope to find some more time in the nearest future to create some post about much more technical aspects and pitfalls.