Behavior Driven Development
17
BEHAVIOR DRIVEN DEVELOPMENT: DELIVERING CODE THAT WORKS HOW THE USERS EXPECT Build better code
-
Upload
adam-englander -
Category
Software
-
view
289 -
download
3
description
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.
Transcript of Behavior Driven Development
BEHAVIOR DRIVEN DEVELOPMENT:
DELIVERING CODE THAT WORKS HOW THE USERS
EXPECT
Build better code
Who Am I?
Adam [email protected]@adam_englanderhttp://adamknowsstuff.comhttps://github.com/derptest
• 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
http://www.slideshare.net/AdamEnglander/behavior-driven-development-35107468
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.
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.
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.
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.
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 resultThe expected outcomeUses Given, When, and Then identifiers
Example Feature (Gherkin)
Feature: Google Web SearchIn 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 webGiven I am on the home page
When I enter a value in the field
When I press “Google Search”
Then there are search results
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
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.
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.
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.
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.
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.
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.
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.
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
