Why adopting behavior-driven development (BDD) is important for software agility

on



I had faced this problem many times when someone ask about a product feature either I have to go through a pile of Jira tickets  or look into the code to see how it works as in agile software development our focus is on delivering working software every few weeks and sometimes documentation takes back seat.

Tickets pile
Due to transnational nature of user stories most of the times it become hard to get bigger picture. I found behavior-driven development (BDD) handy tool in solving this problem. Behavior-Driven Development - “It’s about focusing on the behavior of an application from the point of view of its stakeholders” - Dan North

Test driven development vs. behavior-driven development


BDD uses conversations around examples, expressed in a form that can be easily understood using a common business language to reduce lost information and misunderstandings. The BDD Core is around conversations and requirements discovery. When writing stories; starting with the business outcome, and working through high level functional areas to drill into specific stories with acceptance criteria. Test Scenarios written in business language become the documentation for the feature.
BDD Basics

BDD asks for an Outside-In approach

Express a requirement as a Story

As… I want… So that I…

Define acceptance criteria as scenarios made up of steps

Given… When… Then...

Automate the scenarios

So each step becomes running code



Scenario

  •  Is set of  conditions that story must meet for it to be  accepted as complete
  •  Can be used to help discover the scope of the story or the feature
  • Is not replacement for conversation
  • Is the outcome of conversations with all players 
  •  Scenario title should say what’s different
·         The scenario should be described in terms of Givens, Events and Outcomes

Given [some context]

When [I do something]

Then [this happens]


   How to implement  behavior-driven development (BDD)

Cucumber is one of the most widely used collaboration tool for implementing BDD. It uses outside-In approach, where programmers incrementally write code and run the scenarios using Cucumber until the feature passes all the tests and it helps to execute plain text functional descriptions as automated tests. Automation can be written in own favorite language (Ruby, Java, c#.net, JavaScript, Scala, Groovy, Jython, Python, Perl,  Go, C++ etc.) and writing scenarios before code enables programmers to be guided by an unambiguous specification.

 Scenarios for a feature are grouped in .feature files, and those files contain executable specifications written in a language called Gherkin. Gherkin supports 60+ languages and Gherkin is designed to be easy to learn by non-programmers, yet structured enough to allow concise description of examples to illustrate business rules in most real-world domains.

BDD life-cycle

Comments

Post a Comment