Adam Englander discusses Behavior Driven Development (BDD) as a software methodology that integrates test driven development, domain driven design, and extreme programming. BDD emphasizes documentation of user behavior in plain language understood by business stakeholders, focusing on well-defined feature specifications and scenarios, which enhance collaboration and acceptance testing. The methodology facilitates continuous integration and provides living documentation to keep software development aligned with business needs.

1. Build better code

2. Who Am I?
Adam Englander
adamenglander@yahoo.com
@adam_englander
http://adamknowsstuff.com
https://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

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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