Behavior Driven Development


Published on

An overview of Behavioral Driven Development (BDD). This deck covers the basics with an overview as well as some information on why to use Behavioral Driven Development.

Published in: Software, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Behavior Driven Development

  1. 1. Build better code
  2. 2. Who Am I? Adam Englander @adam_englander • Direct Edge Brands Director of Software Development • Coupla CTO • Founder/Organizer of Las Vegas PHP Users Group • Co-Organizer of Las Vegas Developers Users Group • #VegasTech Enthusiast
  3. 3. What is Behavior Driven Development (BDD)?  BDD is a culmination of multiple software development paradigms:  Test Driven Development (TDD).  Domain Driven Design (DDD).  Extreme Programming (XP).  BDD is a methodology for documenting required user behavior as tests in terms understood by the business stakeholders.
  4. 4. BDD is an extension of Test Driven Development (TDD)  Tests for a feature are written first.  Code is written to make the tests pass.  When all tests pass for a particular feature it is deemed complete.
  5. 5. BDD is an extension of Domain Driven Design (DDD)  Two important tenants of domain driven design are:  Ubiquitous language – a common language for users and developers within the domain of the application.  User validated testing – BDD extends this tenant by specify tests in plain business language not in code.
  6. 6. BDD is an extension Extreme Programming (XP)  BDD defines the actors, purpose, and desired outcome in story format in its definition.  BDD uses scenarios to define expected behavior under specific circumstances.  BDD provides an simple transition from user story to acceptance test.
  7. 7. How a Feature Test is Defined  Title – Short but explicit description of the feature  Narrative – A short narrative describing the who, what, and why of the feature. User story syntax is common: In order to add entries, as a user, I can add an entry.  Scenarios – Descriptions of specific cases for the narrative with the following:  An optional initial condition that is true.  Interactions to trigger a result  The expected outcome  Uses Given, When, and Then identifiers
  8. 8. Example Feature (Gherkin) Feature: Google Web Search In order to perform a web search As an internet user I can enter a search term on the Google home page and search the web Scenario: Searches the web Given I am on the home page When I enter a value in the field When I press “Google Search” Then there are search results
  9. 9. Why BDD?  Better specifications  Better defined acceptance criteria  Business owner driven TDD  Simpler implementation of acceptance tests from DDD  Better understanding of the application context  Continuous integration  Living documentation
  10. 10. Better Specifications With BDD tests, business owners will review and approve testing scenarios. It is an iterative process of designing scenarios to ensure that all scenarios are accounted for and accurate. This process builds a highly accurate suite of acceptance tests that align directly with the business need.
  11. 11. Better Defined Acceptance Criteria When the acceptance criteria is used to build the specification, it is always aligned with the specification. If the tests are written correctly, the feature is complete when the tests are passing. Manual QA will still be needed to verify the tests.
  12. 12. Business Owner Driven TDD Business owners are now defining the tests for test driven development. This makes you tests in TDD more effective and your testing more efficient.
  13. 13. Simpler Implementation of Acceptance Tests From DDD Domain Driven Design (DDD) requires business owners accepting the tests for the domain. Having the users review the BDD tests is much more effective as the non-technical business owners need not understand code logic methodologies to read the tests.
  14. 14. Better Understanding of the Application Context With a proper story definition, the context of the feature is well defined. The who, what, and why is well defined for developers and manual testers. This context definition will allow developers and testers to develop and test with a proper understanding of what they are developing and testing. Understanding the context of a feature request is paramount to delivering the required product.
  15. 15. Continuous Integration The division of BDD testing into individual features lends itself well with continuous integration. Regression testing is done at the feature level and identifying which features are not working as expected is easy to identify. This allows business owners to determine if the application is still releasable with the broken features.
  16. 16. Living Documentation BDD’s features are living documentation to the specifications determined by the business. With an application that is complex or has been iterated upon for multiple years, documentation will undoubtedly fall behind if it is maintained at all. Most of us have had to refer to the code when the business asked us how a particular feature works. With BDD, the tests themselves would accurately define how a particular feature works under relevant scenarios.
  17. 17. What is Good BDD ?  Ubiquitous language  Thorough scenario coverage  Test only what is required  Build only what is required  Constantly test  High visibility to tests and results