This post tackles relatively hot topic in software development and that is “Behaviour Driven Development”(BDD). It insists on defining the term BDD, talks about evolution of BDD, business justification of BDD and finally describes a fitting real world experience. I have made an attempt to cut to the chase and take a stab at the core. This post is for software managers, developers, architects and business analyst.
Background:
We are in a software era of asserting that; ever-increasing complex code base performs what it’s intended to perform even after making a minor to massive modification. This obsession with guaranteed assertion is what resulted in inventing automated unit test cases and consequently, we want an assurance from point of view of business stakeholder, that the software works as expected after critical integration or pre-production.”Which means that, we are not satisfied with code level function testing, which by the way is misleading and non-exhaustive, but we want feature level function testing, giving solid assurance to the business team. “Behaviour” is a contextually loaded word introduced by Dan North in software development, which evokes a notion that we are developing software through the guidelines of how software should act towards the pre-set goal.
Is BDD the evolution of TDD? YES.
Paradigm:
BDD is quite a different paradigm. Different in the sense, that it’s not method/class level validation but at feature level. Also, BDD takes all the pieces and concepts from TDD expect that, looks through the lens of testable working high value features. TDD on the other hand allows one to develop unit test case that asserts the functionality of the given method or a given class. Which is good but hardly protects and convinces the business stake holder’s interest, security and a good night sleep! We need unit test cases woven together to demonstrate and validate a single scenario/feature like for e.g.: What happens in fulfilling the order process requirement?
Real world experience-
I remember working for a healthcare firm where in, the business stakeholder configured a set of input/output pair for a given piece of feature/function, through a web GUI, and the developer’s test case would pick the configured “input”, and perform the corresponding weaving process, through collaboration of different objects and corresponding methods. Thus after executing and asserting (multiple) the behaviour, the output results are matched against the configured output pairs set by the business stakeholder. And subsequently this indicates a green signal at each stage of assertion.
Design Nutcracker 