{"id":5530,"date":"2017-09-29T22:25:36","date_gmt":"2017-09-29T22:25:36","guid":{"rendered":"https:\/\/cheesecakelabs.com\/blog\/?p=5530\/"},"modified":"2022-07-01T17:30:08","modified_gmt":"2022-07-01T17:30:08","slug":"behavior-driven-development","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/behavior-driven-development\/","title":{"rendered":"Behavior-Driven Development: way beyond a testing principle"},"content":{"rendered":"

Picture this: 5 people talking about the same subject in different languages. What are the chances of misunderstanding? As you can imagine: a lot. Well, this is a common scenario in software development teams up to some point. One of the most common reasons that lead to failure when building a product is the lack of well defined goals and requirements amongst developers and stakeholders. This can be caused by a wide variety of reasons. But it is safe to agree that most of them are due to lack of communication.<\/span><\/p>\n

<\/p>\n

Why mention people speaking different languages? <\/span>Because every single collaborator involved in a project has their own perspective<\/b>. The gap might get even bigger when talking about different areas of expertise, such as frontend engineers, testers, backend engineers, data analysts, you name it.<\/span> This can be the equivalent to speaking different languages when it comes to project outcome. As a product owner or business analyst you have to digest the information in a way everyone understands.<\/span><\/p>\n

BDD to the rescue!<\/span><\/h2>\n

BDD stands for Behaviour Driven Development. Originally conceived in 2003 by<\/span> Dan North<\/span><\/a>, it is known to be an <\/span>Agile<\/span><\/a> approach to software development and is emergent in this industry. It aims to do exactly what the title suggests: lead your development driven by behaviour. What does it mean? Behaviour can be described as a feature. A benefit that your product delivers to whomever uses it. BDD was created and designed to give value to stakeholders as its main focus. <\/span><\/p>\n

And how do we achieve all of this? There are some key concepts defined by the BDD approach that address these matters. Let me talk about them.<\/span><\/p>\n

Ubiquitous language<\/span><\/h2>\n

A term from <\/span>Domain-Driven Design<\/span><\/a> for a language shared by developers and business people to reach a common understanding of the terminology in a domain. Remember those 5 characters speaking different languages? Now they all speak the same. This means extending business terminologies all the way down from meetings with stakeholders to your code base. Yes, including database tables and class names too. Domain concepts, the same ones understood and used (or agreed) by users and domains experts should be used throughout the entire project stack. Let\u2019s say that during a banking software development the concept of amortization has been introduced and the project designer calls the referred screen or menu link \u201cPayment in installments\u201d. Ubiquitous language is not being put into practice in this case.<\/span><\/p>\n

Using examples<\/span><\/h2>\n

While explaining theory to someone we tend to use practical examples for better clarity, especially in cases of misunderstanding. The human cognition works better this way. So why not apply it to software development? Why not avoid misunderstandings? Planning and developing through examples is one of the key concepts of BDD. Giving real case scenarios of what you should expect from the product makes sense to everyone. <\/span><\/p>\n

But how? One powerful and well known approach is the use of the Given-When-Then scenarios. Combined with the use of ubiquitous language it describes features with scenarios breaking them down into small stories consisting of 3 phases:<\/span><\/p>\n