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.

About Eric Lefevre-Ardant

Independent technical consultant.
This entry was posted in bdd, tdr. Bookmark the permalink.

2 Responses to Behavior-Driven Development vs. Test-Driven Requirements

  1. ehsavoie says:

    I agree that most of BDD frameworks are developer oriented. But I think that JBehave 2.0 shows some promise here. While you still have most of the features of all other BDD frameworks, the fact that the user stories are written in plain text mode and thus could be easily deported to another tool (like a wiki) gives JBehave an edge.
    Also the fact that the requirements are easily met (plain text files) allows a better integration with developer tools (like svn for example). Some simple text editor with little validation (the fact that you must use BDD ubiquitous language), and maybe wrapper around maven and an svn client (or webdav) should give it all the possibilities of existing TDR solutions with the ease of BDD for the developers.

  2. Pingback: Is Fit Dead? A debate on Twitter « Eric Lefevre-Ardant on Java & Agile

Leave a Reply

Your email address will not be published.