Behavior-Driven Development vs. Test-Driven Requirements

These days, I have had the opportunity to think more about Behavior-Driven Development (BDD) with tools such as JBehave, RSpec, TestDox, and Test-Driven Requirements (TDR) with tools such as Fit, FitNesse, GreenPepper, Concordion. Here are my conclusions.
There is no doubt that BDD helps write tests with a more functional focus. This is also what TDR tools do and there is some overlap.

BDD and TDR help focus on client needs (write the ‘right code’ as opposed to the ‘code right’, as achieved by TDD). However, tooling is more developer-focused for BDD, and business-analyst-focused for TDR.
Therefore, TDR appears to me as a great tool, when business analysts are well integrated with developers. For example, they are part of the same Scrum team, or at least available regularly during the course of an iteration for the Sprint Planning and for conversations aimed at explaining what’s behind the story. TDR helps in making sure that all parties are clear regarding what should be coded (and what has actually been coded), while having no more than a simple user story to begin with. TDR is then mainly a communication tool between technical people and business people.
See a post by James Shore for more on that aspect of TDR.

However, I feel that BDD is an appropriate tool when developers receive specifications from an external team of business analysts, written maybe several iterations earlier. This is not an ideal situation, but it does still occur. In this case, developers should not waste their time with a tool such as Fit which is not the most efficient from their point of view.

BDD also seems great when the whole team is made of very technical people, able to read source code everyday on their own machine. Committers on an Open Source project would be a good example (how often do you ever hear of business analysts contributing to an OSS project?). Another example would be small and focused teams in start-ups that have an excellent understanding of what should be implemented (especially if this team is the one that created the start-up, as it often happens).

Last thought: just like other techniques (such as Pair Programming), it might be that BDD increases cohesion within the team, while creating protection from an outside world that is not as agile as the team. So it is possible that future improvements on the project such as integrating business people in the team might be harder to achieve.

If you can read French, check out this discussion on the XP France mailing list.