BT

Introducing Behaviour-Driven Development

| by Jan Stenberg Follow 38 Followers on Feb 10, 2015. Estimated reading time: 2 minutes |

When the desired outcome of a new project has been defined, Behaviour-Driven Development (BDD) can help in overcoming the gap between the developer’s understanding of what needs to be built and the business’ understanding of the technical challenges caused by the requirements. The reason is improvement in communication between the two groups, Alistair Stead and Konstantin Kudryashov, both working for Inviqa, explains in their Beginner’s guide to BDD, targeting both business and technical professionals.

Stead and Kudryashov divides BDD into two main practices; using examples written in a ubiquitous language to describe behaviour, and using those examples as the basis of automated tests. Together these two practices can validate the functionality for the user and that the system behaves as defined throughout the project lifetime.

The key elements in BDD that Stead and Kudryashov point out include:

  • Creating a goal from a business perspective that preferably is specific and measureable at the start of a project.
  • Impact Mapping, a way of finding the features most important for the business to reach the set goals. An impact map visualizes why features are needed and whose behaviour should be changed to achieve the goals.
  • Complexity analysis, a way to find the most appropriate development and collaboration approach, one example being Cynefin.
  • Planning in examples to avoid misunderstanding by using examples to describe business rules and provide context. These examples should then also be converted into tests used during development.
  • Ubiquitous language, a term from Domain-Driven Design (DDD) for a language shared by developers and business people to reach a common understanding of the terminology in a domain.
  • Development through examples. By using a formal language and an automation tool like Cucumber, examples can be turned into executable specifications for verifying implemented features.
  • The BDD loops enable a support for large changes of a system. Using executable specifications and by treating unit tests as object specifications for how individual pieces of a system should behave, an ability to handle both large and small changes can be achieved.

In an interview with Dan North, who developed BDD around 2006, he emphasizes that BDD is not about testing, it’s about writing examples and expectations to describe behaviour of an application before it exists and by this causing people within a project to talk to each other. North notes the importance of keeping people close to each other, separating structurally or geographically can be a big obstruction to succeeding with BDD.

 

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I follow. by Dzmitry Lahoda

"(BDD) can help in overcoming the gap between the developer’s understanding of what needs to be built and the business’ understanding of the technical challenges caused by the requirements" - I thinks BDD "overcomes gaps" starting from 1-2 minds of developers. Also I prefer instead of "technical" for "detailed consistent logic of all feature interactions".

I follow all steps when possible except `Impact Mapping` and `Complexity analysis`. Seems need to recheck these. Quick look at `Cynefin` suggests that I may use it for debugging and estimations.

It is not possible for me to follow `BDD` when whole project and code and process and mindsets are buildup to opposite attitudes.

I experienced that doing `BDD` on various scales and sizes and layers of software consumers is faster to deliver bug free code in short and long terms then without, even with expense of doing `BDD` steps.

Several times I saw when `Gherkin` used not to define real values for its level of definitions, but on level beneath matching implementation. See www.infoq.com/articles/Spec-Flow. Gherkin should abstract implementation to add more value.

Several times people blamed Gherkin to not support key driven approach or tables or MY_DATA_SOURCE_INPUT or great complexity when number of features grows. Mentally and experimentally I answered all of these concerns, so need to search for article which writes these, or write own.

Regarding `Complexity analysis`, there are various tools which just move analysis from brain to automated visualizations done on computer, with side effect of leaving some documentation and communication medium. Learned via 5 minutes videos on youtube. So I list there some to try

Repertoire Grid for decisions www.infoq.com/news/2012/07/rug-rgt-tool or better openrepgrid.org

Steroided presentation-concept-mind-diagramming tool vue.tufts.edu/ for code, functional, architecture, semantic graph, requirements, and possibly impact mapping modelling.

Lightweight Agile Modelling text UML writing tools like plantuml.sourceforge.net/. So you write some kind of tale in text with formatting and its generated into image with notes.

Tool where just mind up some roles, mind up some work and possibles dependencies. Do software guided input with estimates and dependencies. Then tool suggests what is missed out of via looking at big picture via visualizations like projectlibre.org.

And things I do not see tool yet and not used yet. Graphical notation for logic of feature interactions "If we do A then we need B get leading to options for C or D but preclude E". Like here "Feature Diagrams and Logics: There and Back Again" www.it-c.dk/people/wasowski/papers/czarnecki-wa....

Living Documentation by Jacek Ratzinger

Hi Jan,

Thank you very much for this great article about behavior driven development.

Additionally, to the listed key elements I would like to mention Living Documentation System (specificationbyexample.com/key_ideas.html) as one of the benefits of BDD. When the common understand about features is described with the help of examples, it can be used in future to lookup the intended / expected behavior.

When the specifications with examples are written from the customer perspective we can reach even Specification by Documentation such as described here: concordion.org/dotnet/

The B. word by Jean-Jacques Dubray

Indeed BDD is about "Behavior":
it’s about writing examples and expectations to describe behaviour of an application before it exists and by this causing people within a project to talk to each other.

Unfortunately there is now a well defined way to describe "behavior". I took a stab at a possible metamodel for behavior here.

What I really like about BDD is that it is "state-oriented", in other words BDD clearly specify the start-state and the end-state of the scenario. This is very important because:
1) scenarios can be composed as a graph,
2) states are a lot closer to the problem definition than the solution.

This is unlike user-stories or plain-old-functional-requirements which are "action-oriented" and express the requirements from the solution's point-of-view and cannot be composed as a graph.

Behaviour-driven Design by Alaa Mansour

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
BT