Advantages Of BDD

It is really hard, or almost impossible, to form a two-way communication between groups of people that operate in different business spheres without stumbling upon situations where both sides use the same language and even words, but imply a different meaning.

For example, if building a banking application, you might be asked to implement an ‘account’ feature in the next iteration. If you don’t have enough experience with this particular business or company, you may assume that this feature relates to ‘user accounts’ or ‘user management’ whereas it may refer to the introduction of ‘credit/debit accounts’ into the system. If this misunderstanding isn’t cleared in time by the development team, they could spend anywhere from a couple of weeks (using Agile) to years (using Waterfall) building an ‘account system’ that the client didn’t actually want or need. This problem is generally known as ‘the feedback delay’ or, in this particular case, ‘the cost of translation’.

BDD attempts to eliminate the cost of translation by reducing the size of feedback loops and enforcing the example-based conversation about each feature before they are built. But just asking for examples is not enough, because different sides will use different language to produce examples, eventually causing discrepancies. The solution for this problem is the concept the BDD community borrowed from DDD (Domain Driven Design): ubiquitous language.

Ubiquitous language is a language created by developers and the business in order to discuss features and talk effectively in examples. It is not a technical language, but it is not a business language either; it is a combination of both. The key in the two sides becoming effective for joint communication lies in their ability to accept, to a certain extent, the points of view and understanding of each other. Ubiquitous language is an integral part of BDD. It is almost impossible to be effective with examples without striving for a shared language and understanding.

Examples could take a different form depending on the business and the nature of the ubiquitous language it creates. For example, the stock or banking business domains will most likely use some form of a spreadsheet to provide examples for business processes or important formulas. In the software domain, people tend to use diagrams and technical maps. That said, the most common and adopted format for examples is Given-When-Then which is the format you’ll see most used by the BDD community. It follows a very simple structural agreement.

'Given, describes the initial context for the example
'When' describes the action that the actor in the system or stakeholder performs
'Then' describes the expected outcome of that action