Behavior-Driven Development: The Origins
Behavior-Driven Development: The Origins
In this article, we take a quick look back through the history of BDD, and explore the holes in Specification by Example and Test-Driven Development it was meant to fill.
Join the DZone community and get the full member experience.
Join For FreeThe Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
What do you remember from the 1990s? The launch of the Hubble Space Telescope, when Dolly the Sheep was cloned, or perhaps even when Google began indexing the World Wide Web. During that decade, another term also started floating around: Specification by Example.
“We use realistic examples as a single source of truth for requirements and automated tests on software projects” – Ward Cunningham, A Pattern Language of Competitive Development (1996)
Specification by Example was a breakthrough because it allowed for a more precise method of describing and defining requirements. Testers and developers were able to extract information about requirements through concrete examples rather than abstract specifications. It also provided a new method of helping requirements seem more business readable and better defined.
As the world of software began to advance at a rapid pace and Specification by Example became increasingly diffuse, Test-Driven Development (TDD) coined by Kent Beck was introduced. The popularity of TDD set the tone of what was missing in the marketplace. It was completely driven by technology and was more of a programmer’s discipline rather than that of a tester’s – however, it was also missing a high level and business readable aspect. In 2006, Dan North introduced Behavior-Driven Development (BDD) to fill this void by placing specification on a business level – not through code, but business behavior.*
Fast forward to present day: Agile teams love how BDD allows them to create living documentation that is easy to maintain and can be consumed by all team members, including testers, developers, and product owners. Moreover, tools like Cucumber can leverage BDD scenarios for automated acceptance testing. So why are 80% of BDD projects failing?
In Tricentis Founder Wolfgang Platz’s recent webinar, 'BDD Goes Enterprise', he explains the issues that surround adopting BDD, including when purely open source BDD approaches fall short and elaborating on strategies that can help enterprises scale BDD.
*Dan North, INTRODUCING BDD
Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training.
Like This Article? Read More From DZone
Published at DZone with permission of Jessica Wanivenhaus , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}